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ABSTRACT 

This  document  compiles  the  existing  NIU-Forum  agreements  for  an  ISDN  developed  and  approved  in  the  NIU- 
Forum  as  of  November  1990.  These  agreements  cover:  Layer  1  BRI  at  the  U,  and  S/T  reference  points;  Layer 
1  PRI  at  the  U  reference  point;  Layer  2  BRI  and  PRI;  Layer  3  BRI  Basic  Call  Control  for  Class  I  equipment; 
Layer  3  PRI  Basic  Call  Control  for  Class  II  equipment;  and  Generic  Control  procedures  for  Class  I  BRI 
Supplementary  Services.  In  addition,  this  document  references  the  Conformance  tests  which  have  been 
completed  by  the  NIU-Forum.  These  include:  Layer  1  BRI  S/T  interface;  and  Layer  2  BRI  LAPD.  Finally,  this 
document  contains  the  Application  Profile  for  four  of  the  Incoming  Call  Management  applications  which  have 
been  submitted  to  the  NIU-Forum. 
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NOTICE  OF  DISCLAIMER 


These  agreements  were  developed  and  approved  by  organizations  participating  in  the  North 
American  ISDN  Users'  Forum  (NIU-Forum)  meetings  as  of  November  1990.  In  the  February  1991 
meeting,  participants  tn  the  Plenary  agreed  to  publish  all  agreements  approved  as  of  November 
1990.  The  National  Institute  Of  Standards  And  Technology  (NIST)  makes  no  representation  or 
warranty,  express  or  implied  with  respect  to  the  sufficiency,  accuracy,  or  use  of  any  information 
OR  OPrNION  contained  herein.  The  use  of  this  information  or  opinion  is  at  the  risk  of  the  user. 
Under  no  ctrcumstances  shall  NIST  be  liable  for  any  damage  or  injury  incurred  by  any  person 
arising  out  of  the  sufficiency,  accuracy,  or  use  of  any  information  or  opinion  contained  herein. 
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1  Introduction 

The  purpose  of  the  ISDN  Agreements  document,  its  organization  and  an  overview  of  the  North 
American  ISDN  Users'  Forum  (NIU-Forum)  are  described  in  the  following  subsections. 

1.1  Purpose  of  this  Document 

Participants  in  the  February  1991  NIU-Forum  Plenary  meeting,  approved  a  motion  to  publish  all 
agreements  reached  among  the  members  as  of  November  1990.  This  document  is  a  compilation 
of  these  NIU-Forum  agreements  for  an  ISDN. 

1.2  Evolution  of  this  Document 

New  versions  of  this  document  will  be  issued  as  progress  is  made  in  developing  and  approving 
implementation  agreements,  conformance  tests,  and  application  profdes  within  the  NIU-Forum. 
It  is  the  intent  of  the  NIU-Forum,  that  each  new  version  be  compatible  with  previous  versions. 
Therefore,  each  revision  will  supersede  preceding  versions,  as  each  new  version  wdl  include  all 
of  the  unchanged  agreements  from  previous  versions,  as  well  as  errata  pages  for  previously 
approved  agreements. 

1.3  Document  Organization 

The  ISDN  Agreements  document  is  organized  into  specific  sections  as  follows: 

•  Section  1 

Introduction  —  The  purpose  of  this  document,  the  document  organization,  and  an 
overview  of  the  structure  and  organization  of  the  NIU-Forum. 

•  Section  2 

ISDN  Versions  —  A  specific  interoperable  subset  of  an  ISDN  which  functions  in  a  multi- 
vendor  environment. 

•  Section  3 

Implementation  Configurations  —  A  categorization  of  the  ISDN  capabdities,  based  upon 
access  and  equipment  class  information. 

•  Section  4 

Implementation  Agreements  —  The  Implementation  Agreements  (IAs)  are  developed  by 
both  implementor  and  user  representatives  participating  in  the  NIU-Forum  Expert  Working 
Groups.  The  IAs  provided  in  this  section  allow  for  expeditious  development  of  ISDN 
capabilities,  and  promote  interoperability  of  ISDN  communications  equipments. 

•  Section  5 

ISDN  Conformance  Test  Specifications  —  Conformance  Test  (CT)  suites  for  an  ISDN 
are  detailed  in  this  section  of  the  agreements. 

•  Section  6 

Application  Software  Interface  —  The  Application  Software  Interface  (ASI)  section  will 
focus  on  the  definition  of  a  common  application  interface  for  accessing  and  administering 
ISDN  services  provided  by  Network  Adapters. 
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•  Section  7 

Application  Profiles  —  The  Application  Profiles  (APs)  contain  the  recommended  set  of 
agreements  and  specifications  for  all  layers  and  aspects  of  ISDN  communication  which 
must  be  present  to  support  a  particular  users'  application  or  set  of  applications  (application 
family). 

•  Section  8 

References  —  The  References  section  provides  a  listing  of  documents  identified  but  not 
included  in  this  publication. 

1,4  NIU-Forum  Overview 

The  following  text  introduces  the  NIU-Forum  purpose  and  organization. 

1.4.1  Purpose  of  the  Forum 

The  Integrated  Services  Digital  Network  (ISDN)  is  defined  in  a  group  of  international 
recommendations  for  a  worldwide  communications  network  for  the  exchange  of  all  information 
(voice,  data,  and  image)  among  all  users,  independent  of  any  manufacturer,  service  provider,  or 
implementation  technology. 

ISDN  recommendations  are  being  developed  by  the  International  Telephone  and  Telegraph 
Consultative  Committee  (CCITT).  In  North  America,  the  ISDN  standards  are  being  developed  by 
Committee  Tl,  which  is  accredited  by  the  American  National  Standards  Institute  (ANSI)  and 
sponsored  by  the  Exchange  Carriers  Standards  Association  (ECSA). 

The  result  is  one  extensive  standard  with  a  tremendous  variety  of  options  and  parameters.  This 
is  necessary  to  meet  all  the  possible  needs  and  technologies  for  which  the  standards  could  be  used. 
However,  to  ensure  interoperability  and  terminal  portability  within  the  ISDN  network  and  its 
attendant  terminals  and  other  Customer  Premises  Equipment  (CPE),  a  uniform  subset  of  these 
options  and  parameters  must  be  selected.  Each  application  usually  only  requires  a  subset  of 
functionality  and  in  order  for  products  to  work  together  in  a  multi-vendor  environment,  common 
sets  of  options  must  be  selected. 

To  cope  with  this  proliferation  of  choices  and  to  provide  practical  products  and  services  which 
meet  users'  needs,  the  specification  process  must  be  extended  to  include  Application  Profiles, 
Implementation  Agreements,  and  Conformance  tests  to  promote  interoperability. 

1.4.2  NIU-Forum/NIST  Relationship 

The  North  American  ISDN  Users'  Forum  has  created  a  user  voice  in  the  implementation  of  ISDN 
and  ISDN  applications  and  has  helped  to  ensure  that  the  emerging  ISDN  environment  meets  users' 
application  needs.  The  NIU-Forum  is  sponsored  by  the  National  Institute  of  Standards  and 
Technology  (NIST).  The  precise  relationship  of  the  NIU-Forum,  NIST,  and  other  business 
concerns  is  defined  by  the  "Cooperative  Research  and  Development  Agreement:  The  Consortium 
on  ISDN  Based  Systems."1 


1-2 


i 


For  more  information,  contact  the  NIU-Forum  Administrator  (see  sec.  1.5). 
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1.4.3  NIU-Forum  Organization  and  Procedures 

The  actual  work  of  the  NIU-Forum  is  accomplished  in  two  workshops;  the  ISDN  Users'  Workshop 
(IUW)  and  the  ISDN  Implementors'  Workshop  (IIW).  These  workshops,  which  consist  of  various 
working  groups  and  special  project  teams,  meet  several  times  a  year  and  develop  the  following 
products:  Application  Requirements,  Application  Analyses,  Application  Profiles,  Implementation 
Agreements,  Conformance  Criteria,  and  an  Applications  Software  Interface.  The  IUW  produces 
Application  Requirements  which  describe  potential  applications  of  ISDN  and  the  features  which 
may  be  required. 

The  HW  develops  Application  Analyses,  Application  Profiles,  Implementation  Agreements, 
Conformance  Criteria,  and  an  Applications  Software  Interface  which  provide  the  technical  detail 
necessary  to  implement  an  Application  Requirement  in  an  interoperable  manner. 

The  activities  within  the  two  workshops  are  coordinated  by  the  NIU-Forum  Executive  Steering 
Committee.  While  specifics  of  the  NIU-Forum  organization  follow,  particulars  relating  to  the 
procedures  for  the  NIU-Forum  are  found  in  the  "North  American  ISDN  Users'  Forum  Practices 
Manual."2 

1.4.3.1  ISDN  Users'  Workshop  (IUW) 

The  IUW  is  responsible  for  identifying,  defining,  and  prioritizing  user  requirements,  as  well  as 
working  with  the  HW  to  define  and  approve  agreements  necessary  to  support  the  implementation 
of  user  requirements.  Membership  in  the  IUW  is  open  to  any  organization.  Users  participating 
in  the  IUW  are  organized  into  seven  Industry  Groups:  Manufacturing  Industries,  Process 
Industries,  Service  Industries,  Small  Business,  Financial  Services,  Government,  and  Computing  and 
Telecommunications  Industries.  The  IUW  organization  emphasizes  the  synergy  present  when 
organizations  from  the  same  industry  segment  work  together  to  define  applications.  Activities 
within  the  IUW  are  coordinated  by  the  IUW  Steering  Committee. 

The  IUW  work  program  is  based  on  identifying  potential  user  applications  and  structuring  the  IIW 
work  to  satisfy  the  user  applications.  Any  user  can  request  consideration  for  a  particular  ISDN 
application.  The  request  should  be  for  an  application  which  could  be  used  to  support  business 
related  operations.  It  is  important  that  ISDN  solutions  to  business  problems  be  based  on  business 
considerations  which  include: 

•  cost  reductions 

•  productivity  enhancements 

•  standard  application  interfaces 

•  and  performance  improvements. 

For  a  detailed  description  of  the  "User  Application"  Processing  within  the  ISDN  Users'  Workshop, 
please  refer  to  section  1.3.4.2  of  the  North  American  ISDN  Users'  Forum  (NIU-Forum)  Working 
Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  1,  (Ref.  [32]). 


2  For  more  information,  please  contact  the  NIU-Forum  Administrator  (see  sec.  1.5). 
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1.4.3.2  ISDN  Implementors'  Workshop  (HW) 

The  IIW  is  responsible  for  developing  Application  Analyses,  Application  Profiles,  Implementation 
Agreements,  Conformance  Criteria,  and  an  Applications  Software  Interface  in  support  of  IUW 
defined  Application  Requirements.  The  IIW  also  provides  technical  advice  and  consultation  to  the 
IUW,  sponsors  multi-vendor  demonstrations  and  trials,  and  provides  formal  liaisons  with 
appropriate  organizations  such  as  the  Corporation  for  Open  Systems  (COS),  the  Open  Systems 
Interconnection  (OSI)  Implementors'  Workshop  (OIW),  or  the  ANSI  Accredited  Standards 
Committee  Tl.  Membership  in  the  IIW  is  open  to  any  organization. 

The  IIW  Steering  Committee  is  responsible  for  coordinating  the  activities  of  the  IIW  groups.  The 
IIW  is  organized  into  the  following  groups: 

•  Applications  Analysis  Working  Group  (WG) 
»  Application  Profile  Teams 

•  Expert  WGs 

•  ISDN  Conformance  Test  (ICOT)  WG. 

The  Applications  Analysis  WG  develops  an  analysis  of  the  user's  application  requirements,  which 
serves  as  a  basis  for  development  of  the  Application  Profile  by  the  Applications  Profile  Teams. 
The  Expert  WGs  produce  the  Implementation  Agreements  that  are  generally  based  on  ANSI 
standards.  In  addition,  there  is  an  Expert  WG  defining  an  Applications  Software  Interface.  The 
ICOT  WG  defines  conformance  requirements  and  develops  abstract  test  suites  for  Implementation 
Agreements  and  Application  Profiles. 

1.4.4  ISDN  Versions 

A  version  defines  and  specifies  ISDN  as  it  exists  at  a  certain  point  in  time  as  derived  from  existing 
national  and  international  standards  and  other  consensus  activities.  Each  version  should  be 
completely  compatible  with  earlier  versions.  Manufacturers  and  service  providers  would  be 
expected  to  develop  ISDN  offerings  based  on  a  particular  version. 

1.5  Point  of  Contact 

Further  information  about  the  NIU-Forum  can  be  obtained  by  contacting: 
NIU-Forum  Secretariat 

National  Institute  of  Standards  and  Technology 
Building  223,  Room  B364 
Gaithersburg,  Maryland  20899 
(301)  975-2937 

For  information  regarding  specific  groups  or  activities  within  the  NIU-Forum  please  refer  to  the 
appropriate  representative  listed  in  Attachment  2  of  section  1  in  the  North  American  ISDN  Users' 
Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  — 
Publication  1,  (Ref.  [32]),  which  lists  the  chairs,  vice  chairs,  secretariats,  and  emeriti  members  of 
the  NIU-Forum  Executive  Steering  Committee  (ESC),  IIW,  and  IUW. 
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2  Future  ISDN  Versions 


Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  definition  and 
specification  of  ISDN  Versions.  Refer  to  section  2.0  of  the  North  American  ISDN  Users'  Forum 
(NIU-Forumj  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  — 
Publication  1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work  within  the  NIU- 
Forum. 
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3  Implementation  Configurations 


The  ISDN  architecture  is  intended  to  interconnect  all  user  and  network  equipments,  in  a  ubiquitous 
fashion,  to  provide  a  common  network  encompassing  all  possible  communication  scenarios. 
Because  of  this  broad  scope,  the  national  standards  for  the  ISDN  could  not  be  universally  applied 
to  all  the  conceivable  combinations  of  equipment  types,  access  arrangements  and  applications.  The 
concept  of  implementation  configurations  is  introduced  to  allow  specific  ISDN  capabilities 
(procedures)  to  be  associated  with  a  class  of  equipment,  an  access  arrangement,  or  an  application. 

The  use  of  the  equipment  class/access  arrangement  terminology  permits  clarification  of  the 
circumstances  under  which  a  certain  capability  should  be  available  (i.e.,  when  a  particular 
equipment  class  is  in  use).  It  also  permits  a  mechanism  for  indicating  that  a  particular  capability 
applies  only  to  a  subset  of  four  possible  configurations. 

The  implementation  configurations,  which  were  defined  by  the  NIU-Forum  Signalling  Working 
Group  (SWG),  have  been  applied  to  the  Layer  3  circuit-switched  signalling  protocols  only.  Future 
work  will  evaluate  the  implementation  configuration  concept  for  applicability  to  all  agreements 
emerging  from  the  NIU-Forum. 

The  following  text  provides  the  current  description  of  implementation  configurations  from  the 
SWG: 

The  concept  of  equipment  classes  is  introduced  in  this  document  to  permit  certain  procedures  to 
be  associated  with  a  particular  application  or  class  of  equipment,  e.g.,  station  equipment  versus 
(Private  Branch  Exchange  (PBX).  Specifically,  two  classes  of  equipment  are  defined  on  the  basis 
of  two  fundamental  attributes. 

The  first  attribute  relates  to  the  possibility  of  an  exchange  of  signals  occurring  beyond  the  public 
network's  point  of  contact  with  the  interface  (i.e.,  between  the  equipment  directly  connected  to  the 
public  network  and  ISDN  terminals  or  telephones  connected  to  that  equipment).  For  example, 
some  user  equipment  may  support  subtending  Basic  Access  digital  subscriber  loops  and/or  analog 
telephone  loops.  For  Class  I  equipment,  the  network  makes  no  provision  for  such  an  arrangement 
and  assumes  the  Class  I  equipment  constitutes  the  endpoint  of  the  communication.  Conversely, 
in  the  case  of  Class  II  equipment,  the  procedures  at  the  network  take  into  account  that 
communication  between  Class  II  equipment  (with  which  it  communicates  directly)  and  other 
equipment  (with  which  the  network  does  not  have  direct  contact)  may  occur.  As  an  example,  Class 
II  equipment  may  support  digital  and/or  analog  subscriber  loops.  Use  of  Class  II  equipment  also 
involves  the  possibility  of  having  interworking  occur  beyond  the  equipment  with  which  the  network 
has  direct  contact.  Therefore,  it  is  reasonable  for  Class  II  equipment  to  provide  the  network  with 
an  interworking  notification,  for  both  outgoing  and  incoming  calls,  when  either  the  calling  or  called 
party  respectively,  is  a  non-ISDN  user.  Class  II  equipment  may  also  send  an  interworking 
notification,  if  a  private  network  exists  beyond  the  Class  n  equipment  and  interworking  to  a  non- 
ISDN  facility  within  that  network  takes  place.  When  an  interface  is  associated  with  Class  I 
equipment,  it  is  assumed  that  multiple  pieces  of  equipment  may  exist  and  communicate  with  the 
network  over  the  D-channel.  However,  in  this  case,  all  equipment  is  assumed  to  be  ISDN-capable 
and  is  considered  as  the  endpoint  of  the  communication.  Therefore,  interworking  notification 
should  not  be  accepted  from  Class  I  equipment. 

The  second  attribute  relates  to  the  manner  in  which  a  SETUP  message,  the  message  which  initiates 
an  ISDN  call,  should  be  presented  to  the  user  equipment.  When  Class  I  equipment  is  applied  on 
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a  particular  interface,  the  network  should  broadcast  the  SETUP  message  associated  with  each  call 
that  terminates  on  that  interface,  since  interaction  between  the  network  and  multiple  pieces  of  user 
equipment  should  be  supported.  On  the  other  hand,  the  network  should  not  broadcast  SETUP 
messages  associated  with  terminating  calls  to  an  interface  on  which  Class  II  equipment  is  being 
used.  Here,  a  single  piece  of  user  equipment  is  assumed  to  be  involved  in  all  communication  with 
the  network. 

To  the  extent  possible,  it  is  desirable  to  have  one  set  of  requirements  for  ISDN  call  control  apply 
to  all  ISDN  user  configurations.  However,  in  cases  for  which  integrated  procedures  are  not 
appropriate,  the  call  control  procedures  associated  with  Equipment  Class  I  will  differ  from  those 
associated  with  Equipment  Class  II.  Unless  otherwise  noted,  the  assumption  should  be  that  a 
particular  procedure/capability  should  be  provided  for  both  classes  of  equipment  on  both  basic  and 
primary  rate  access.  However,  use  of  the  equipment  class  terminology  permits  clarification  of  the 
circumstances  under  which  a  certain  capability  should  be  available  (i.e.,  when  a  particular 
equipment  class  is  in  use).  It  also  permits  a  mechanism  for  indicating  that  a  particular  capability 
applies  only  to  a  subset  of  four  possible  configurations  which  are  labeled  as  follows. 

Table  3-1.  Implementation  Configurations 


Class  I  Class  n 


BRI 
PRI 


IB 

IIB 

IP 

IIP 

In  other  words,  a  capability  that  applies  to  Class  I  equipment  may  be  provided  on  basic  access 
interfaces  (IB)  and/or  primary  rate  access  interfaces  (IP).  Similarly,  a  capability  that  applies  to 
Class  II  equipment  may  be  provided  on  basic  access  interfaces  (IIB)  and/or  primary  rate  access 
interfaces  (IIP). 

The  notation  shown  in  the  table  above  is  used  within  this  implementation  agreement  to  indicate 
when  protocol  or  procedures  are  only  expected  to  be  supported  for  a  particular  class  and/or  are 
limited  to  a  particular  type  of  interface,  i.e.,  basic  or  primary  rate  interface. 
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4  Implementation  Agreements 


The  Implementation  Agreements  (IAs)  generated  by  the  NIU-Forum  IIW  provide  the  agreements 
for  implementing  the  American  National  Standard  (ANS)  specifications  for  an  ISDN.  These  IAs 
were  developed  and  approved  by  both  industry  and  user  representatives  participating  in  the  Expert 
Working  Groups,  as  well  as  the  NTU-Forum  Plenary.  The  IAs  exist  to  expedite  the  development 
of  ISDN  capabilities,  to  promote  interoperability  of  ISDN  communications  equipments,  and  to 
provide  a  universal,  multi-vendor  implementation.  The  following  text  details  the  IAs.3 

4.1  ISDN  Lower  Layer  Specifications 

The  ISDN  lower  layer  specifications  define  the  Layer  1,  2,  and  3  requirements  of  an  ISDN. 
Network  signalling,  via  the  D-channel,  is  the  focus  of  these  agreements  but,  where  appropriate, 
user  data  specifications  of  Layers  1,  2,  and  3  have  been  included.  These  IAs  were  developed  in 
the  Signalling  Expert  Working  Group  (SWG)  of  the  IIW.  These  IAs  provide  a  framework  and  a 
set  of  protocol  procedures  for  accessing  an  ISDN  so  that  systems  implemented  according  to  these 
agreements  can  successfully  intemperate.  The  following  text  details  the  ISDN  lower  layer  IAs. 

4.1.1  Layer  1  Basic  Rate  Interface  (BRI) 

The  ISDN  Basic  Rate  Interface  (BRI)  physical  layer  specifications  are  defined  for  their  specific 
reference  point  of  application.  These  reference  points  are  S,  T  and  U,  providing  the  user  and 
network  interfaces  for  Terminal  Equipment  (TE)  and  Network  Termination  (NT)  equipments.  The 
following  IAs  are  defined  for  the  BRI  physical  layer. 

4.1.1.1  U  Reference  Point 

The  IA  (NIU  89-101)  for  the  U  reference  point  states:  the  physical  layer  of  the  Basic  Access 
Interface  at  the  U  reference  point  is  specified  in  ANS  Tl.601-1988,  Integrated  Services  Digital 
Network — Basic  Access  Interface  for  Use  on  Metallic  Loops  for  Application  on  the  Network  Side 
of  the  NT  —  Layer  1  Specification,  (Ref.  [12]). 

The  IA  has  adopted  the  ANS  Tl.601-1988  (Ref.  [12])  standard  without  exception. 

4.1.1.2  S  and  T  Reference  Points 

The  IA  (NIU  89-105)  for  the  S/T  reference  point  states:  the  physical  layer  of  the  Basic  Access 
Interface  at  the  S  and  T  reference  points  is  specified  in  ANS  T  1.605- 1989,  Integrated  Services 
Digital  Network  —  Basic  Access  Interface  at  S  and  T  Reference  Points  —  Layer  1  Specification, 
(Ref.  [16]). 

The  IA  has  adopted  the  ANS  Tl.605-1989  (Ref.  [16])  standard  without  exception. 

4.1.2  Layer  1  Primary  Rate  Interface  (PRI) 

The  ISDN  Primary  Rate  Interface  (PRI)  physical  layer  specifications  are  defined  for  their  specific 
reference  point  of  application.  These  reference  points  are  the  S,  T  and  U,  providing  the  user  and 


The  NTU-Forum  Plenary  document  numbers  (e.g.,  NIU  89-101)  are  included  for  reference  purposes 
only,  as  every  numbered  implementation  agreement  is  included  in  the  present  document  in  its 
entirety. 
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network  interfaces  for  TE  and  NT  equipments.  The  following  IAs  are  defined  for  the  PRI  physical 
layer. 


4.1.2.1  U  Reference  Point 


The  I A  (NTU  89-103)  for  the  U  reference  point  states:  the  physical  layer  of  the  Primary  Access 
Interface  is  governed  by  ANS  Tl. 403- 1989,  Carrier  to  Customer  Installation  —  DS1  Metallic 
Interface,  (Ref.  [10]),  and  CCITT  Recommendation  1.431-1988,  Primary  Rate  User  —  Network 
Interface  —  Layer  1  Specification,  (Ref.  [24]). 

The  following  provisions  of  ANS  Tl.403-1989  (Ref.  [10]),  are  excluded  from  the  ISDN  Primary 
Rate  Interface  IA: 


1. 

section  5.3.1: 

The  bit  rate  tolerance  of  +/-200  bil/s. 

2. 

section  5.6: 

The  minimum  pulse  density  requirements  of  this  section. 

3. 

section  6.1: 

The  superframe  format  (SF). 

4. 

section  6.3: 

The  complete  section. 

5. 

section  8.0: 

The  reference  to  the  superframe  format  (SF). 

6. 

section  8.3: 

The  text  in  paragraph  8.3.1.1  and  footnote  7  (8.3.1.2). 

7. 

section  8.4.1: 

Footnote  9. 

8. 

section  9/Figure  9: 

Provisions  for  the  use  of  the  RJ48M  connector. 

9. 

Table  1: 

This  Table. 

10 

Table  2: 

The  illustration  in  Table  2  of  Robbed-Bit  Signalling. 

The  following  provisions  of  ANS  Tl.403-1989  (Ref.  [10]),  shall  be  modified  for  the  ISDN  Primary 
Rate  Interface  IA: 


1.  section  5.3.2:  The  text  of  this  section  is  replaced  by  the  statement,  "The  line  code  is 

B8ZS  except  as  noted  in  section  7." 

2.  section  7.0:  The  reference  to  the  pulse  density  requirements  of  section  5.6  is 

inappropriate.  The  text  is  replaced  by:  "The  provision  of  Clear 
Channel  Capability  (CCC)  depends  upon  the  use  of  the  B8ZS  line  code, 
though  the  use  of  ZBTSI  is  one  interim  method  that  may  be  employed 
by  agreement  of  the  network  and  the  user." 

The  provisions  of  ANS  Tl.403-1989  (Ref.  [10]),  shall  be  supplemented  by  the  provisions  of  section 
4.4  of  the  CCnT  Recommendation  1.431-1988,  (Ref.  [24]). 


This  IA  is  currently  based  upon  the  ANS  Tl.403-1989  (Ref.  [10]),  standard  (the  DS1 
specification).  The  ANSI  accredited  technical  subcommittee  T1E1  has  recently  completed  a 
standard  for  the  ISDN  Primary  Access  Interface  at  the  reference  points  S,  T  and  U  (ANS  T 1.408- 
1990,  Integrated  Services  Digital  Network  (ISDN)  —  Primary  Rate  Customer  Installation  Metallic 
Interfaces  —  Layer  1  Specification,  Ref.  [11]).  This  IA  is  currently  undergoing  changes  to 
reference  it.4 


4  This  IA  (NIU  89-103)  has  been  revised  to  adopt  ANS  Tl.408-1990  (Ref.  [1 1])  without  exception. 
This  revision  (NTU  91-103  Rl)  is  still  undergoing  approval  by  the  NIU-Forum,  and  will  be 
published  in  the  next  version  of  the  NIU-Forum  ISDN  Agreements  document. 
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4.1.2.2  Future  S  and  T  Reference  Points 


Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  Layer  1  PRI  S  and  T 
Reference  Points.  Refer  to  section  4.1.2  of  th&North  American  ISDN  Users'  Forum  (NfU-Forwn) 
Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  1 ,  (Ref. 
[32]),  for  information  regarding  the  current  status  of  this  work  within  the  NTU-Forum. 

4.1.3  Layer  2  BRI  and  PRI 

The  ISDN  Basic  Rate  Interface  (BRI)  and  Primary  Rate  Interface  (PRI)  access  arrangements 
specifies  one  common  IA  for  the  D-channel  Layer  2  data  link. 

The  IA  (NIU  89-210)  for  the  ISDN  data  link  layer  states:  the  data  link  layer  of  the  D-channel  is 
specified  in  ANS  Tl.602-1989,  ISDN  Data-Link  Layer  Signalling  Specification  for  Application  at 
the  User-Network  Interface,  (Ref.  [13]). 

The  IA  has  adopted  the  ANS  Tl.602-1989  (Ref.  [13])  standard  with  the  following,  additional 
clarifications: 

1)  Both  automatic  and  non-automatic  Terminal  Endpoint  Identifier  (TEI)  assignment  terminals 
shall  be  allowed  to  connect  to  a  passive  bus.  Automatic  TEI  assignments  are  preferred,  since  it 
would  be  the  responsibility  of  the  user  to  ensure  that  different  TEIs  are  used  by  each  different 
terminal  for  non-automatic  TEI  allocation  equipment. 

2)  It  is  recommended  that  the  data  link  monitor  function  be  operated  on  at  least  one  link 
associated  with  each  TEI. 

4.1.4  Layer  3  BRI  and  PRI 

The  ISDN  BRI  and  PRI  access  arrangements  will  utilize  the  Layer  3  Signalling  protocol  as  defined 
by  ANS  Tl.607-1990,  ANS  Tl.608-1990  and  ANS  Tl.610-1990  (Refs.  [17,  18,  20]).  These 
specifications  apply  to  two  distinct  connection  types:  circuit-switched  and  packet-switched.  The 
following  text  details  the  IAs  for  ISDN  Layer  3  signalling. 

4.1.4.1  Circuit-Switched  Call  Control  Procedures 

The  circuit-switched  Layer  3  signalling  protocol  shall  be  responsible  for  the  establishment, 
maintenance  and  tear-down  of  basic  signalling  connections  and  supplementary  service  signalling 
connections  which  utilize  circuit-switched  access.  The  following  text  details  the  circuit-switched 
call  control  procedures. 

4.1.4.1.1  Basic  Call  Control  Procedures 

The  IAs  (NIU  300  Series)  for  the  ISDN  Basic  Call  Control  procedures  state:  the  circuit-switched 
network  layer  protocol  is  specified  in  the  ANS  Tl.607-1990,  Digital  Subscriber  Signalling  System 
No.  1  (DSS1) — ISDN  Layer  3  Signalling  Specification  for  Circuit-Switched  Bearer  Service,  (Ref. 
[17]). 

The  IAs  have  adopted  ANS  Tl.607-1990  (Ref.  [17]),  according  to  the  implementation 
configurations,  as  follows: 
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Class  I  BRI  (IB) 


The  Class  I  BRI  (IB)  basic  call  control  signalling  IA  (NIU  90-301)  is  included  in  Appendix  A. 

•  Future  Class  I  PRI  (IP) 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Class  I  PRI  (IP)  basic  call 
control  signalling.  Refer  to  section  4.1.4.1  of  the  North  American  ISDN  Users'  Forum  (NIU- 
Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication 
1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work  within  the  NIU-Forum. 

•  Future  Class  II  BRI  (IIB) 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Class  II  BRI  (IIB)  basic 
call  control  signalling.  Refer  to  section  4.1.4.1  of  the  North  American  ISDN  Users'  Forum  (NIU- 
Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication 
1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work  within  the  NIU-Forum. 

•  Class  II  PRI  (IIP) 

The  Class  E  PRI  (IIP)  basic  call  control  signalling  IA  (NIU  90-302)  is  included  in  Appendix  B. 
4.1.4.1.2  Supplementary  Services  Control  Procedures 

The  IAs  (NTU  310  Series)  for  the  ISDN  Supplementary  Services  Control  procedures  are  based 
upon  ANS  Tl.610-1990,  Digital  Subscriber  Signalling  System  No.  1  (DSS1)  —  Generic  Procedures 
for  the  Control  of  ISDN  Supplementary  Services,  (Ref.  [20]).  The  following  text  details  the  IAs. 

•  Class  I  BRI  (IB) 

The  IA  (NIU  89-311)  for  the  Class  I  BRI  (IB)  Supplementary  Services  Control  procedures  states: 
The  generic  procedures  for  the  control  of  ISDN  Supplementary  Services  for  Class  I  equipment  on 
a  Basic  Rate  Interface  (BRI)  is  specified  in  ANS  Tl.610-1990  (Ref.  [20]). 

The  following  changes  shall  apply  to  the  ANS  Tl.610-1990  (Ref.  [20])  specification: 

1.  In  section  4,  the  Keypad  protocol  only  applies  during  the  establishment  phase  of  a  call; 

2.  In  section  5.2.2.1,  the  option  of  using  the  dummy  call  reference  for  sending  a  call- 
associated  feature  request  is  removed. 

3.  In  section  2.1.3,  section  6,  and  Appendix  I,  the  Common  Information  Element  Category 
of  the  Functional  Protocol  is  removed; 

4.  In  section  7,  the  FACILITY  and  REGISTER  messages  are  removed; 

5.  In  section  8,  the  Facility  information  element  is  removed; 

6.  In  Annex  A,  the  Terminal  Identification  procedures  for  assignment  of  USID  and  TID  at 
subscription  time  are  removed; 

7.  In  Annex  B,  section  2.1,  the  words  "in  the  Called  party  number  information  element  in 
one  or  more  INFORMATION  messages"  should  be  changed  to  "in  the  Called  party 
number  information  element  in  one  INFORMATION  message;" 

8.  Remove  Appendix  III  General  Description  of  Component  Encoding  Rules. 

9.  The  scope  of  this  implementation  agreements  is  applicable  only  to  the  ISDN  Basic  Access 
Rate  as  applied  to  Class  I  equipment. 
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Future  Class  I  PRI  (IP) 


Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Class  I  PRI  (IP) 
Supplementary  Services  Control  procedures.  Refer  to  section  4.1.4.1  of  the  North  American  ISDN 
Users'  Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network 
(ISDN)  —  Publication  1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work 
within  the  NIU-Forum. 

•  Future  Class  II  BRI  (IIB) 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Class  II  BRI  (IIB) 
Supplementary  Services  Control  procedures.  Refer  to  section  4.1.4.1  of  the  North  American  ISDN 
Users'  Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network 
(ISDN)  —  Publication  1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work 
within  the  NIU-Forum. 

•  Future  Class  II  PRI  (IIP) 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Class  II  PRI  (IIP) 
Supplementary  Services  Control  procedures.  Refer  to  section  4.1.4.1  of  the  North  American  ISDN 
Users'  Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network 
(ISDN)  —  Publication  1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work 
within  the  NIU-Forum. 

4.1.4.2  Packet-Switched  Call  Control  Procedures 

The  Lower  Layer  Special  Interest  Group  (LLSIG),  of  the  OSI  Implementors'  Workshop  (OIW), 
has  the  responsibility  of  developing  the  IAs  for  packet-switched  connections.  Their  work  overlaps 
with  the  packet-switched  services  provided  by  an  ISDN.  Therefore,  the  SWG  has  the  responsibility 
to  review  the  LLSIG's  IAs  and  provide  to  the  LLSIG  any  additional  information/clarification 
necessary  to  align  these  IAs  with  those  defining  the  ISDN. 

The  packet-switched  layer  3  signalling  protocol  shall  be  responsible  for  the  establishment, 
maintenance  and  tear-down  of  basic  signalling  connections  and  supplementary  service  signalling 
connections  which  utilize  packet-switched  access.  The  following  text  details  the  packet-switched 
call  control  procedures. 

The  IA  (NIU  89-320)  for  the  ISDN  Basic  Call  Control  procedures  states:  the  packet-switched 
network  layer  protocol  is  specified  in  the  CCITT  Recommendation  Q.93 1-1988  (also  designated 
CCITT  Recommendation  1.451-1988),  ISDN  User-Network  Interface  Layer  3  Specification,5  (Ref. 
[26]). 

The  following  agreements  have  been  reached  concerning  the  use  of  CCITT  Recommendation 
Q.93 1-1988,  (Ref.  [26]): 


5  This  IA  will  be  aligned  with  ANS  Tl  .608-1990,  Digital  Subscriber  Signalling  System  No.  1  (DSS1 ) 
—  Signalling  Specification  f or  X. 25  Packet  Switched  Bearer  Service  (Ref.  [18])  when  ANS  T1.608- 
1990  is  stable.  Please  refer  to  section  4.1.4.2  of  the  North  American  ISDN  Users'  Forum  (NIU- 
Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication 
1  (Ref.  [32])  for  more  information  on  this  alignment 
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1.  On  a  BRI  supporting  the  ISDN  virtual  circuit  service,  all  of  CCITT  Recommendation  Q.931- 
1988  (Ref.  [26])  section  6,  except  for  6.1.1  and  6.2.1  (the  sections  covering  the  circuit-switched 
access  case),  shall  apply.  The  following  sections  also  apply;  3.2  (messages  for  packet-mode  access 
connection  control),  4-4.5  (section  specifying  general  information  element  handling  and  encoding), 
4.7  (information  elements  for  packet  communications). 

2.  On  a  PRI  supporting  the  ISDN  virtual  circuit  service  all  of  Q.931-1988  (Ref.  [26])  section  6, 
except  for  6.1.1  and  6.2.1  (the  sections  covering  the  circuit-switched  access  case),  6.1.2.2,  6.2.2.2 
and  6.4.2  (the  sections  specifying  the  D-channel  ISDN  virtual  circuit  service  case),  shall  apply. 
The  following  sections  also  apply:  2.2  (packet-mode  access  connection  states),  3.2  (messages  for 
packet-mode  access  connection  control),  4-4.5  (section  specifying  general  information  element 
handling  and  encoding),  4.7  (information  elements  for  packet  communications). 

3.  On  a  BRI  or  PRI  supporting  the  Unrestricted  64  kbit/s  circuit-mode  service,  CCITT 
Recommendation  Q.931-1988  (Ref.  [26])  sections  6.1.1,  6.2.1,  6.4.1  and  6.4.3  shall  apply.  The 
following  sections  also  apply:  2.1  (circuit-mode  connection  states),  3.1  (messages  for  circuit-mode 
connection  control),  4-4.5  (section  specifying  general  information  element  handling  and  encoding). 

4.2  Future  Basic  Bearer  Services  Specification 

The  ISDN  basic  bearer  services  specifications  define  the  minimal  set  of  bearer  services  provided 
by  an  ISDN.  The  specifications  outline  the  set  of  essential  bearer  services,  and  their  attributes,  to 
be  provided  by  an  ISDN.  The  IAs  developed  for  the  bearer  services  will  provide  a  specification 
outlining  the  required  bearer  services  and  their  respective  characteristics.  The  following  text  will 
detail  the  ISDN  basic  bearer  services  IAs. 

4.2.1  Future  Minimal  Set  of  BRI  Services 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  minimal  set  of  ISDN 
Basic  Rate  Interface  (BRI)  bearer  services.  Refer  to  section  4.2.1  of  the  North  American  ISDN 
Users'  Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network 
(ISDN)  —  Publication  I,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work 
within  the  NIU-Forum. 

4.2.2  Future  Minimal  Set  of  PRI  Services 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  minimal  set  of  ISDN 
Primary  Rate  Interface  (PRI)  bearer  services.  Refer  to  section  4.2.2  of  the  North  American  ISDN 
Users'  Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network 
(ISDN)  —  Publication  1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work 
within  the  NIU-Forum. 

4.3  Future  Supplementary  Services  Specification 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  ISDN  supplementary 
services  specifications.  Refer  to  section  4.3  of  the  North  American  ISDN  Users'  Forum  (NIU- 
Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication 
1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work  within  the  NIU-Forum. 
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4.4  ISDN  Terminal  Adaptation  Specification 

The  ISDN  Terminal  Adaptation  specifications  define  the  requirements  for  attaching  a  non-ISDN 
terminal  to  an  ISDN.  This  attachment  is  performed  across  the  R  reference  point,  with  the 
specification  of  the  R  reference  point  providing  the  necessary  characteristics,  attributes  and 
functions  such  that  successful  interoperability  between  the  non-ISDN  and  the  ISDN  is  achieved. 
The  IAs  developed  for  terminal  adaptation  provide  a  specification  of  the  R  reference  point 
requirements.  The  following  text  details  the  ISDN  terminal  adaptation  IAs. 

4.4.1  Future  Circuit-Mode  Data  Terminal  Adaptation 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  circuit-mode  data  terminal 
adaptation  which  will  define  the  R  reference  point  requirements  when  circuit-switched  connections 
are  provided  by  an  ISDN.  Refer  to  section  4.4.1  of  the  North  American  ISDN  Users'  Forum  (NIU- 
Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication 
1,  (Ref.  [32]),  for  the  information  regarding  the  current  status  of  this  work  within  the  NTU-Forum. 

4.4.2  Packet-Mode  Data  Terminal  Adaptation 

The  packet-mode  data  terminal  adaptation  IAs  define  the  aspects  of  the  packet-mode  services  to 
be  used  by  the  packet-mode  DTE,  the  access  requirements,  and  the  functions  of  the  Terminal 
Adaptor  provided  across  the  R  reference  point.  These  IAs  were  developed  in  the  LLSIG  of  the 
OSI  Implementors'  Workshop.  Refer  to  section  7  of  the  NIST  OSI  Implementors'  Workshop 
Stable  Implementation  Agreements  for  OSI  Protocols  (Ref.  [42]). 

4.5  ISDN  Management  Specification 

The  ISDN  Management  specifications  provide  the  operations  and  maintenance  requirements  for  the 
various  access  interfaces  and  protocol  levels  of  the  ISDN.  The  IAs  are  to  be  developed  in  the 
Network  Management  Expert  Working  Group  (NMWG)  of  the  IIW.  The  following  text  details  the 
ISDN  Management  IAs. 

4.5.1  Future  Layer  1  BRI 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Layer  1  ISDN  management 
specification,  for  a  Basic  Rate  Interface  (BRI).  Refer  to  section  4.5.1  of  the  North  American  ISDN 
Users'  Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network 
(ISDN)  —  Publication  1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work 
within  the  NIU-Forum. 

4.5.2  Future  Layer  1  PRI 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Layer  1  ISDN  management 
specification,  for  a  Primary  Rate  Interface  (PRI).  Refer  to  section  4.5.2  of  the  North  American 
ISDN  Users'  Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network 
(ISDN)  —  Publication  1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work 
within  the  NIU-Forum. 
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4.5.3  Future  Layer  2  and  3,  BRI  and  PRI 


Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Layer  2  and  3  ISDN 
management  specification,  for  a  Basic  Rate  Interface  (BRI)  and  a  Primary  Rate  Interface  (PRI). 
Refer  to  section  4.5.3  of  the  North  American  ISDN  Users'  Forum  (NIU-Forum)  Working 
Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  1,  (Ref.  [32]),  for 
information  regarding  the  current  status  of  this  work  within  the  NIU-Forum. 

4.6  Future  Common  Channel  Signalling  —  Signalling  System  #7 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  common  channel  signalling 
system,  ANSI  Signalling  System  #7  (Refs.  [1,  2,  3,  4,  5,  6,  19].  Refer  to  section  4.6  of  the  North 
American  ISDN  Users'  Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services 
Digital  Network  (ISDN)  —  Publication  I,  (Ref.  [32]),  for  information  regarding  the  current  status 
of  this  work  within  the  NIU-Forum. 
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5  ISDN  Conformance  Test  Specifications 

The  NIU-Forum's  Conformance  Test  (CT)  specifications  provide  test  suites  to  be  used  to  verify 
the  conformance  of  ISDN  equipments  to  the  designated  specification.  They  are  written  in  abstract 
form  so  that  multiple  test  equipment  vendors  may  provide  implementations  of  the  test  suite.  The 
ISDN  Conformance  test  specifications  are  developed  in  the  ISDN  Conformance  Test  (ICOT) 
Working  Group,  and  its  subordinate  Expert  Working  Groups:  the  Abstract  Conformance  Test 
Group  for  Layer  1  (ACT1)  and  the  Abstract  Conformance  Test  Group  for  Layers  2  and  3  (ACT23). 
The  following  text  details  the  Conformance  Tests  for  ISDN  equipments. 

5.1  Layer  1  BRI 

The  Basic  Rate  Interface  (BRI)  Layer  1  Conformance  Test  specifications  provide  the  requirements 
for  verifying  equipment  conformance  at  Layer  1  of  the  ISDN  BRI  user-network  interface.  The 
following  text  details  the  Conformance  Tests  for  Layer  1  operation  of  a  BRI. 

•  Future  "U"  Interface 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  Layer  1  BRI 
conformance  test  abstract  test  suites,  and  conformance  criteria  to  the  ANS  Tl.601-1988  (Ref.  [12]). 
Refer  to  section  5.1  of  the  North  American  ISDN  Users'  Forum  (NIU-Forum)  Working  Agreements 
for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  1,  (Ref.  [32]),  for  information 
regarding  the  current  status  of  this  work  within  the  NRJ-Forum. 

•  The  "S/T"  Interface 

The  CT  defining  the  conformance  criteria  and  abstract  test  suites  to  verify  equipment 
implementation  conformance  to  the  BRI  S  and  T  interface  as  specified  in  ANS  Tl. 605- 1989  (Ref. 
[  16])  is  defined  by  the  NIU-Forum  specification,  NKJ  90-002  (NIU-F/HW/ICOT-90-040)  Integrated 
Services  Digital  Network  (ISDN)  Conformance  Testing,  Layer  1  Basic  Rate  SIT  Interface,  User 
Side,  (Ref.  [33]). 

5.2  Future  Layer  1  PRI 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  Layer  1  PRI 
conformance  test  abstract  test  suites,  and  conformance  criteria  to  the  ANS  Tl.601-1988  (Ref.  [12]). 
Refer  to  section  5.2  of  the  North  American  ISDN  Users'  Forum  (NIU-Forum)  Working  Agreements 
for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  1,  (Ref.  [32]),  for  information 
regarding  the  current  status  of  this  work  within  the  NIU-Forum. 

5.3  Layer  2  BRI 

The  Layer  2  Conformance  Test  specifications,  for  the  BRI  and  PRI  access  arrangements,  provide 
the  requirements  for  verifying  equipment  conformance  at  Layer  2  of  the  ISDN  BRI/PRI.  The 
ISDN  test  suite  development  process  is  aligned  with  ISO  9646  (Ref.  [43]),  OSI  Conformance 
Testing  Methodology  and  Framework,  Parts  1-3.  The  following  text  details  the  Conformance  Tests 
for  Layer  2  operation  of  an  ISDN. 
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The  CT  defining  the  abstract  test  suites  to  verify  equipment  implementation  conformance  to  the 
Layer  2  of  an  ISDN  at  the  user-network  interface  is  defined  by  the  NIU-Forum  specification,  NTU 
91-0076  (NTU-Forum/irW/ICOT/ACT-9 1/22.2  V1.2)  "Integrated  Services  Digital  Network  (ISDN) 
Conformance  Testing,  Layer  2  Basic  Rate  Interface,  Link  Access  Procedure,  D-channel  (LAPD), 
User  Side,"  (Ref.  [34]).  This  conformance  test  suite  is  for  the  Link  Access  Procedure  D-channel 
(LAPD)  data  link  protocol  and  is  described  in  Tree  and  Tabular  Combined  Notation  (TTCN).  Its 
use  is  for  ISDN  terminal  equipments  attaching  to  the  user  side  of  a  Basic  Access  interface. 

The  CT  defines  the  conformance  criteria  to  the  ANS  Tl. 602- 1989  (Ref.  [13])  and  to  the  CCITT 
Recommendation  Q.921-1988  (Ref.  [25])  (Note:  These  specifications  are  the  same  text).  The 
purpose  of  the  Abstract  Test  Suite  is  to  provide  the  most  complete  protocol  conformance  test 
coverage  as  is  possible,  not  to  be  completely  exhaustive.  The  LAPD  Test  Suite  has  many 
additional  test  cases  for  TEI  Management  procedures  and  system  related  cases  which  are  covered 
in  the  body  of  the  CCITT  Recommendation  Q.921-1988  text  (Ref.  [25])  but  not  in  the  CCITT 
Recommendation  Q.921-1988  state  transition  tables. 

5.4  Future  Layer  2  PRI 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  Layer  1  PRI 
conformance  test  abstract  test  suites,  and  conformance  criteria  to  the  ANS  Tl.602-1989  (Ref.  [13]). 

5.5  Future  Layer  3 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  Layer  3  Conformance 
Test  specifications,  for  BRI  and  PRI  access  arrangements.  Refer  to  section  5.4  of  the  North 
American  ISDN  Users'  Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services 
Digital  Network  (ISDN)  —  Publication  1,  (Ref.  [32]),  for  the  information  regarding  the  current 
status  of  this  work  within  the  NIU-Forum. 
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6  Future  Application  Software  Interface  (ASI) 


Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  the  definition  and 
specification  of  the  Application  Software  Interface.  Refer  to  section  6.0  of  the  North  American 
ISDN  Users'  Forum  (NIL 1 -Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network 
(ISDN)  —  Publication  1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work 
within  the  NTU-Forum. 
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7  Application  Profiles 


Since  the  inception  of  the  NIU-Forum,  the  goal  has  been  to  provide  an  ISDN  that  users  want  and 
need,  and  to  do  so  in  a  way  that  promotes  application  interoperability  in  a  multi-vendor 
environment.  Application  profiles  are  the  final  step  in  the  functional  standardization  process  to 
achieve  this  goal. 

7.1  NIU-Forum  Application  Profiles 

An  application  profile  provides  an  overall  specification  of  the  ISDN  elements  and  the  application 
elements  necessary  to  provide  a  specific,  interoperable  application  for  an  ISDN.  A  profile  supports 
a  particular  application,  or  a  set  of  applications,  specifying  the  ISDN  standards  to  use,  the  options 
to  implement  within  each  standard,  the  layered  protocol  configuration  and  the  application's  usage 
of  the  ISDN's  attributes.  Please  refer  to  section  7.1.1  of  the  North  American  ISDN  Users'  Forum 
(NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  — 
Publication  1,  (Ref.  [32]),  for  a  description  of  the  process  for  developing  Application  Profiles. 

7.1.1  Application  Profile  Conformance 

It  is  essential  that  the  Application  Profile  teams  identify  criteria  that  the  implementor  must  meet 
in  order  to  claim  compliance  with  the  Application  Profile.  It  is  intended  that  a  tester  agency  be 
established  (e.g.,  the  Corporation  for  Open  Systems)  which  applies  ICOT-derived  conformance  tests 
in  order  to  verify  a  product's  relative  sufficiency  of  interoperability  against  a  testbed  which  applies 
standardized  testing  methodologies  (e.g.,  ISO  9646,  Ref.  [43]).  Real  multi-vendor  interoperability 
is  achieved  in  an  interoperability  testing  environment  which  validates  the  Application  Profile's 
compliance  amongst  participatory  users  and  vendors. 

7.2  Application  Profile  Families 

The  NTU-Forum  ISDN  applications  have  been  categorized  into  one  of  six  "application  families." 
The  families  provide  a  means  of  assimilating  applications  based  upon  a  commonality  of  usage. 

Each  family  has  been  assigned  its  own  Application  Profile  team  to  develop  the  Application  Profiles 
for  the  family.  The  following  Application  Profile  teams  have  been  identified: 

•  ISDN  Call  Management 

•  ISDN  CPE  Compatibility/Capability 

•  ISDN  Network  Interconnectivity 

•  Messaging  and  Answering 

•  Bandwidth  Negotiation 

•  Network  Management/ISDN  Administration 

The  following  text  details  the  Application  Profile  IAs.7 
7.2.1  ISDN  Call  Management 

The  ISDN  Call  Management  Profile  team  has  completed  an  Application  Profile,  NIU  90-003,  for 
incoming  call  management  which  covers  all  of  the  following  applications: 


The  NIU-Forum  Plenary  document  numbers  (e.g.,  NIU  90-003)  are  included  for  reference  purposes 
only,  as  every  numbered  application  profile  is  included  in  the  present  document  in  its  entirety. 
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Title 


User  Req't  Document  Number 


•  Database  Information  to  Corporate  Security 


810005 


•  New  Account  Customer  Inquiry  Handling 


840023 


•  Customer  Service  Call  Handling 


840024 


•  Automatic  Callback  for  Financial  Services 


840025 


7.2.1.1  Abstract 

This  application  profile  provides  the  User  Descriptions,  Alternative  Architectures,  Information 
Hows,  and  recommended  Protocol  Stacks  for  the  Incoming  Call  Management  Applications  (User 
Application  Requirements  Data  Form  Numbers:  810005,  840023,  840024,  840025,  Refs.  [35,  36, 
37,  38]).  The  Incoming  Call  Management  Applications  involve  customer  service  agents  who 
currently  receive  incoming  calls,  ask  the  caller  for  their  member  number,  and  input  that  data  into 
a  terminal  connected  to  a  host  application.  ISDN  will  be  used  to  automate  the  transfer  of  the 
Caller's  ID  to  the  host.  In  addition,  agents  may  transfer  the  call  to  an  additional  agent  who  should 
be  able  to  continue  the  call  without  having  to  request  the  same  information  from  the  caller  again. 
ISDN  will  be  used  to  effect  the  call  transfer  and  allow  the  second  agent  to  bring  up  the  right 
application  screen  without  repeating  questions.  Finally,  when  all  the  agents  are  busy,  the  caller's 
number  should  be  captured  for  later  callback.  ISDN  will  be  used  to  capture  the  caller's  number 
and  allow  callback  later.  ISDN  can  be  used  to  connect  the  agent's  terminal  to  the  host. 

7.2.1.2  User  Description 

Customer  service  agents  currently  receive  incoming  calls,  ask  the  caller  for  their  member  number, 
and  then  input  the  member  number  into  a  terminal  connected  to  a  host  application  to  obtain  the 
customer  information.  Agents  may  transfer  the  customer  to  another  agent  to  provide  a  different 
service.  The  second  agent  has  to  again  ask  for  the  member  number  and  enter  a  transaction  to 
receive  the  customer  information.  The  second  agent  may  access  a  different  host  application.  In 
addition,  when  all  agents  are  busy,  the  caller's  number  should  be  captured  for  later  callback. 

7.2.1.3  ISDN  Application  Breakdown 

The  user's  proposed  application  and  the  breakdown  of  the  application  into  service  elements  can 
be  seen  in  figure  7-1. 

•  Call  Transfer  with  Associated  Data  Service  Element 

Agent  1  wishes  to  transfer  a  voice  call  from  the  Customer  to  agent  2.  The  voice  call  is 
transferred  to  agent  2.  Certain  information  associated  with  the  terminal  session  is 
transferred  to  the  host  to  which  agent  2  is  attached,  so  that  the  appropriate  screen  can  be 
delivered  to  agent  2. 

•  Call  Delivery  with  Associated  Data  Service  Element 

The  customer  places  a  voice  call  in  order  to  speak  to  an  agent.  The  call  arrives  at  a 
Central  Office  (Co)  or  Customer  Premises  switch  (PBX).  The  switch  delivers  the  voice 
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call  to  agent  l.8  Certain  information  that  is  delivered  to  the  switch  with  the  voice  call 
(probably  the  calling  party's  number)  is  delivered  to  a  host  application,  so  that  the  host 
application  can  deliver  an  appropriate  screen  to  agent  1. 

•  Call  Back  on  Busy/Abandonment  Service  Element 

This  service  allows  an  available  agent  to  place  calls  to  customers  who  have  received  busy 
or  abandoned  the  call  prior  to  delivery  to  an  agent. 

•  Terminal  Connectivity  Service  Element 

The  agents  data  terminal  is  connected  to  the  host  via  an  ISDN  link. 
7.2.1.3.1  Service  Logic 

Figure  7-2  shows  the  sequence  of  services  put  together  to  provide  Incoming  Call  Management 
Applications.  The  Terminal  Connectivity  Service  Element  may  be  optional  and  a  Call  coming  in 
without  the  associated  data  (Calling  Line  Identification  (CLID)  may  be  available  for  Call  Transfer 
with  associated  data. 

7.2.1.4  Call  Transfer  with  Associated  Data  Service  Element 

In  this  service  a  call  is  already  active  between  agent  1  and  the  caller.  Agent  1  could  then  perform 
any  of  the  following: 

1.  Blind  Transfer  —  Transfer  the  call  to  a  second  agent  and  disconnect  before  the 
second  agent  answers. 

2.  Transfer  with  Consulting  —  Transfer  the  call  to  a  second  agent,  discuss  the  call  with 
the  second  agent,  then  complete  the  transfer. 

3.  Consult  —  Agent  1  calls  the  second  agent  to  discuss  the  call  and  then  disconnects 
agent  2. 

The  components  are  shown  in  figure  7-3. 
The  sequence  of  events  for  each  type  is: 
Blind  Transfer 

a.  Agent  1  places  the  caller  on  hold. 

b.  Agent  1  places  a  call  to  agent  2  and  invokes  transfer. 

c.  Agent  1  hangs  up. 

d.  Agent  2  is  selected  directly  or  by  an  intervening  CO/PBX  (Automatic  Call 
Distributor  (ACD)  function). 


8     The  topic  of  how  the  switch  decides  to  deliver  the  call  to  a  particular  agent  has  not  been  described 
as  part  of  this  application,  but  may  have  some  bearing  on  implementation. 
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e.  Agent  2  receives  the  voice  call,  while  concurrently  a  host9  application  brings  up 
an  appropriate  screen  based  on  some  information  delivered  with  the  call  to  agent 

2. 

Transfer  with  Consulting 

a.  Agent  1  places  the  caller  on  hold. 

b.  Agent  1  places  a  call  to  agent  2. 

c.  Agent  2  is  selected  directly  or  by  an  intervening  CO/PBX  (ACD  function). 

d.  Agent  2  receives  the  voice  call,  while  concurrently  a  host  application  brings  up 
an  appropriate  screen  based  on  some  information  delivered  with  the  call  to  agent 
2. 

e.  Agent  1  talks  with  agent  2. 

f.  Agent  1  transfers  the  caller  to  agent  2  and  disconnects. 
Consulting 

a.  Agent  1  places  the  caller  on  hold. 

b.  Agent  1  places  a  call  to  agent  2. 

c.  Agent  2  is  selected  directly  or  by  an  intervening  CO/PBX  (ACD  function). 

d.  Agent  2  receives  the  voice  call,  while  concurrently  a  host  application  brings  up 
an  appropriate  screen  based  on  some  information  delivered  with  the  call  to  agent 
2. 

e.  Agent  1  talks  with  agent  2. 

f.  Agent  2  disconnects. 

The  information  being  passed  along  with  the  call  will  be  called  the  Key.  The  Key  may  be  any  of 
the  following: 

•  a  database  key  used  by  the  agent's  application, 
the  Calling  Party  Number, 

an  Application  or  Screen  ID, 

some  other  information  used  by  the  users  application, 

•  or  a  combination  of  the  above. 


9  The  host  that  the  application  is  running  on  may  be  the  same  for  both  agents  or  different. 
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7.2.1.4.1  User  Environment 

Some  of  the  users'  descriptions  of  the  service  have  specified  a  hardware  and  software  environment 
in  which  the  service  should  work.  At  a  minimum,  the  service  should  work  in  the  following 
environment: 

IBM  3270f  type  terminals 
An  IBM-compatible  host 

SNA  (Systems  Network  Architecture)  host  networks. 

These  are  minimum  requirements  and  the  actual  description  of  the  service  is  more  general  in  that 
it  will  work  with  other  terminals,  hosts,  and  networks. 

7.2.1.4.2  Alternative  Architectures 

Two  architectures  for  this  application  have  been  proposed  and  adopted  (March  1989  and  June  1989 
NTU-Forum).  The  first  architecture  calls  for  the  Call  information  to  be  delivered  to  the  agent's 
station  or  terminal  adaptor  (TA)10  and  then  have  that  device  transmit  it  to  the  host  application  (see 
fig.  7-4).  If  the  agent's  station  is  sufficiendy  intelligent  (e.g.,  a  personal  computer),  the  station 
could  run  the  application  locally. 

The  second  architecture  calls  for  the  Host  to  provide  the  central  office  or  customer  premises  switch 
with  the  Key,  and  that  Key  is  passed  to  agent  2's  Host  (see  fig.  7-5).  The  call  is  delivered  to  the 
agent's  station  normally.  The  data  terminal  could  be  attached  to  the  host  direcdy  or  be  attached 
using  the  ISDN  Terminal  Connectivity  Service  Element  described  in  section  7.2.1.7. 

7.2.1.4.3  Information  Flow 

The  information  flow  diagrams  show  that  data  that  must  be  sent  between  nodes  necessary  to 
provide  the  service  described.  Signalling  messages  that  are  normally  present  (i.e.,  confirmation 
messages,  error  messages,  disconnect)  are  not  shown  for  simplicity  if  they  are  not  necessary  to 
explain  the  working  of  the  service. 

The  information  flow  for  Architecture  1  —  Smart  Terminal/TA  can  be  seen  in  figure  7-6. 

Agent  1  places  a  call  (Call  Setup)  which  is  delivered  to  agent  2's  station  with  the  Key  (carried  as 
User  to  User  information).  Agent  2's  station  could  generate  an  appropriate  screen  using  the  Key 


Trademark  of  IBM  Corporation 

This  requires  intelligence  not  normally  associated  with  a  TA  to  satisfy  the  requirement  that  any 
3270-like  device  were  to  be  able  to  use  this  service.  A  separate  functional  entity,  and  Intelligence 
Unit  (IU),  will  be  described  as  providing  the  service  of  relaying  Call  information  to  the  host  In 
effect  this  unit  would  upgrade  the  3270  to  an  intelligent  terminal  with  an  attached  voice  terminal. 
The  TA-intelligence  unit  will  have  to  be  able  to  have  a  separate  session  to  the  host  running,  so  the 
data  can  be  passed.  Alternately,  but  more  complex,  the  Intelligence  Unit  would  have  to  be  able 
to  understand  the  screens  being  passed  between  the  host  and  the  terminal  and  insert  information 
in  the  data  stream. 
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Figure  7-4.       Call  Transfer  with  Data  Service  Element  Architecture  1  —  Smart  Terminal/TA. 
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or  the  station  could  then  transfer  the  Key  to  the  host.  The  host  application  would  then  select  and 
transmit  the  appropriate  screen  to  agent  2's  terminal. 

The  information  flow  for  Architecture  2  —  Switch  Host  interface  can  be  seen  in  figure  7-7. 

The  call  would  be  initiated  by  agent  1  selecting  to  transfer  via  the  terminal.  The  terminal  would 
transfer  this  information  to  the  host  ("Init  Call").  The  host  would  then  transmit  this  to  the  PBX/CO 
along  with  the  Key  as  User  to  User  information  ("Init  Call  (Key)").  The  PBX/CO  the  second  agent 
is  attached  to  would  transmit  the  call  setup  information  to  agent  2's  station.  Simultaneously  the 
PBX/CO  would  send  the  call  setup  information  (including  the  user  to  user  information  containing 
the  Key)  to  the  host  computer.  The  host  selects  and  transmits  the  appropriate  screen  to  agent  2's 
terminal. 

In  both  flows,  if  consulting  is  desired  instead  of  completing  the  transfer,  agent  2  would  disconnect. 

7.2.1.4.4  Network  Signalling  Requirements  —  Protocol  Identification 

The  network  signalling  requirements  for  providing  this  service  with  each  architecture  are  shown 
in  figures  7-8  and  7-9.  Not  shown  is  how  the  call  was  originally  received,  since  it  may  have  come 
in  via  ISDN  or  POTS.  The  requirement  for  this  capability  is  that  the  end-points  involved  in  the 
call  transfer  must  be  connected  via  end-to-end  ISDN  signalling  so  that  user-to-user  information  can 
be  exchanged. 

In  the  figures  7-8  and  7-9  any  connection  between  two  devices  without  a  specific  protocol  marked 
may  use  any  applicable  protocol  including  a  proprietary  one. 

7.2.1.4.5  Protocol  Description 

The  messages  and  protocol  elements  described  below  are  only  those  required  by  the  service  being 
described.  Other  messages  and  protocol  elements  are  not  discussed  if  they  are  not  used  by  the 
application  being  described,  even  through  they  may  be  required  for  other  reasons,  such  as  routing 
of  the  call. 

7.2.1.4,5.1  Call  Setup  User  Information 

The  Key  can  be  carried  from  the  origination  to  destination  terminal  in  the  SETUP  message 
described  in  NTU  90-301  (see  Appendix  A)  and  NTU  90-302  (see  Appendix  B).  The  SETUP 
Message  described  as  sent  to  the  network  and  by  the  network  to  the  called  user  to  initiate  call 
establishment. 

The  information  element  used  to  carry  the  Key  would  be  the  User-User  information  element 
described  as  follows:  "The  purpose  of  the  User-user  information  element  is  to  convey  information 
between  ISDN  users.  This  information  is  not  interpreted  by  the  network,  but  rather  is  carried 
transparently  and  delivered  to  the  remote  user(s).  There  are  no  restrictions  on  the  content  of  the 
user  information." 


NIU-Forum  Agreements  On  ISDN 


7-11 


Agent  1 


Agent  2 


HOST  1 


Notificatio 


Init  Call 


n  of  Call 


Initiation 


Call 
Transfer 


PBX/CO 
(ACD) 


Init  Call 
(Key) 


Call 
Transfer 


PBX/CO 
(ACD) 


Call  Setup 
IKejO 


HOST  2 


User  Info 
iKey) 


Call 


SEND(SCREEN) 


Setup 


Figure  7-7. 


Host  1  and  Host  2  may  be  the  same 
PBX/CO  and  PBX/CO'  may  be  the  same 

Call  Transfer  with  Data  Service  Element  Switch  Host  Interface  —  Information  Flow 

Diagram. 


Agent  1 


Agent  2 


ISDN\  ISDN 
BRI 


HOST 


if 


ISDN 


ISDN 
BRI 


PBX/CO 
(ACD) 


PBX/CO 
(ACD) 


HOST 


Figure  7-8. 


Call  Transfer  with  Data  Service  Element  Smart  Terminal/TA 
Requirements. 


Network  Signalling 


7-12 


NIU-Forum  Agreements  on  ISDN 


Agent  1 


Agent  2 


D  0  0 
ODD 


HOST 


ISDN 
(SCAI) 


ISDN 


ISDN 
Network 


ISDN 


PBX/CO 
(ACD) 


PBX/CO 
(ACD) 


ISDN 
(SCAI) 


HOST 


Figure  7-9. 


Call  Transfer  with  Data  Service  Element  Switch  Host  Interface 
Requirements. 


Network  Signalling 


NIU-Forum  Agreements  On  ISDN 


7-13 


7.2.1.4.5.2  Call  Transfer 


Proposed  baseline  text  for  the  Normal  Call  Transfer  supplementary  service  exists  within  T1S  1.2/91 - 
309,  Supplementary  Service  —  Normal  Call  Transfer  Stage  1,  2,  and  3,  (Ref.  [22]).u  There  is 
no  consensus  on  the  protocol  description  for  this  service  yet. 

7.2.1.4.5.3  Host-Switch  Messages 

The  functions  that  need  to  be  provided  to  allow  this  service  are  the  following: 
•     Send  User-User  information  (Key)  and  initiate  a  call. 
Receive  User-User  information  (Key)  on  an  incoming  call. 

Possibly  initiate  the  call  transfer  operation,  this  could  be  done  from  the  voice  terminal 
directly. 

The  Host  Computer  messages  are  being  described  in  the  ANSI  Switch-Computer  Applications 
Interface  (SCAI)  Working  Document,  T1S  1.1/9 1-387  (Ref.  [23]).  Section  5  of  the  SCAI  working 
document  described  the  DATA/VOICE  COORDINATION  ASE  "which  may  be  used  by  an 
Application  Process  on  either  a  switch  or  a  computer  to  exchange  information  and  commands  for 
the  purpose  of  coordinating  voice  and  data  services."  The  protocol  definition  is  currently  for 
further  study. 

7.2.1.5  Call  Delivery  with  Associated  Data  Service  Element 

In  this  service  an  agent  is  available  to  receive  an  incoming  call.  When  a  customer's  call  is 
presented  to  the  agent  an  appropriate  screen  is  displayed  on  the  agent's  data  terminal  that  relates 
to  the  caller  or  the  application  being  provided  by  the  agent  (see  fig.  7-10). 

The  sequence  of  events  is  as  follows: 

a.  Caller  places  a  call  to  the  phone  number  of  the  "Call  Delivery  service  user"  (800 
number  in  some  User's  application). 

b.  An  agent  is  selected  by  the  CO/PBX  (ACD  function). 

c.  The  agent  receives  the  voice  call,  while  concurrently  a  host  application  brings  up  an 
appropriate  screen  (based  upon  the  calling  party's  number). 

7.2.1.5.1  User  Environment 

Some  of  the  users'  descriptions  of  the  service  have  specified  a  hardware  and  software  environment 
in  which  the  service  should  work.  At  a  minimum,  the  service  should  work  in  the  following 
environment: 

IBM  3270  type  terminals 


11     There  is  also  ongoing  work  within  ANSI  to  define  Explicit  Call  Transfer  and  Single  Step  Call 
Transfer  Supplementary  Services. 
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An  IBM-compatible  host 


SNA  host  networks. 

These  are  minimum  requirements  and  the  actual  description  of  the  service  is  more  general  in  that 
it  will  work  with  other  terminals,  hosts,  and  networks. 

7.2.1.5.2  Alternative  Architectures 

Two  architectures  for  this  application  have  been  proposed  and  adopted  (March  1989  and  June  1989 
NIU-Forum).  The  first  architecture  calls  for  the  Call  information  to  be  delivered  to  the  agent's 
station  or  terminal  adaptor  (TA)12  and  then  have  that  device  transmit  it  to  the  host  application  (see 
fig.  7-11).  If  the  agent's  station  is  sufficiently  intelligent  (e.g.,  a  personal  computer),  the  station 
could  run  the  application  locally. 

The  second  architecture  calls  for  the  Host  to  provide  the  central  office  or  customer  premises  switch 
with  the  Key,  and  that  Key  is  passed  to  agent  2's  Host  (see  fig.  7-12).  The  call  is  delivered  to  the 
agent's  station  normally.  The  data  terminal  could  be  attached  to  the  host  directly  or  be  attached 
using  the  ISDN  Terminal  Connectivity  Service  Element  described  in  section  7.2.1.7. 

7.2.1.5.3  Information  Flow 

The  information  flow  diagrams  show  the  data  that  must  be  sent  between  nodes  necessary  to  provide 
the  service  described.  Signalling  messages  that  are  normally  present  (i.e.,  confirmation  messages, 
error  messages,  disconnect)  are  not  shown  for  simplicity,  if  they  are  not  necessary  to  explain  the 
working  of  the  service. 

The  information  flow  for  Architecture  1  —  Smart  Terminal/TA  can  be  seen  in  figure  7-13. 

The  call  is  delivered  to  the  agent's  station  with  the  Calling  Party  Number  (CPN).  The  station  will 
generate  an  appropriate  screen  locally  or  by  interacting  with  a  host  application. 

The  information  flow  for  Architecture  2  —  Switch  Host  interface  can  be  seen  in  figure  7-14. 

The  Switch  transmits  the  call  setup  information  to  the  agent's  station  and  the  host  computer 
simultaneously.  The  host  selects  and  transmits  the  appropriate  screen. 


12  This  requires  intelligence  not  normally  associated  with  a  TA  to  satisfy  the  requirement  that  any 
3270-like  device  were  to  be  able  to  use  this  service.  A  separate  functional  entity,  and  Intelligence 
Unit  (IU),  will  be  described  as  providing  the  service  of  relaying  Call  information  to  the  host.  In 
effect  this  unit  would  upgrade  the  3270  to  an  intelligent,  terminal  with  an  attached  voice  terminal. 
The  TA-intelligence  unit  will  have  to  be  able  to  have  a  separate  session  to  the  host  running,  so  the 
data  can  be  passed.  Alternately,  but  more  complex,  the  Intelligence  Unit  would  have  to  be  able 
to  understand  the  screens  being  passed  between  the  host  and  the  terminal  and  insert  information 
in  the  data  stream. 
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Figure  7-11.      Call  Delivery  with  Data  Service  Element  Architecture  1  —  Smart  Terminal/TA. 

 Agent  1  


Caller 


ISDN 
Switched  Network 


□  00 

□  DO 

□  a  □ 

ODD 


Calling  Party 


Number 


HOST 


Figure  7-12.      Call  Delivery  with  Data  Service  Element  Architecture  2  —  Switch  Host  Interface. 
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7.2.1.5.4  Network  Signalling  Requirements  —  Protocol  Identification 

In  order  to  implement  this  service,  certain  signalling  capabilities  are  required  in  the  user  and  carrier 
networks.  Figures  7-15  and  7-16  identify  what  are  the  signalling  requirements  at  each  point  in  the 
network.  As  can  be  seen  in  me  diagrams  the  requirements  for  signalling  within  the  network  are 
the  same  for  the  smart  terminal  and  switch-host  scenarios,  but  there  are  differences  within  the 
premises. 

EAMF  stands  for  Equal  Access  Multi-Frequency  which  can  be  used  to  pass  the  Calling  Party 
Number.  Any  connection  between  two  devices  without  a  specific  protocol  marked  may  use  any 
applicable  protocol  including  a  proprietary  one. 

7.2.1.5.5  Protocol  Description 

The  messages  and  protocol  elements  described  below  are  only  those  required  by  the  service  being 
described.  Other  messages  and  protocol  elements  are  not  discussed  if  they  are  not  used  by  the 
application  being  described,  even  through  they  may  be  required  for  other  reasons,  such  as  routing 
of  the  call. 

7.2.1.5.5.1  Call  Setup  User  Information 

The  Calling  Party  Number  can  be  carried  from  the  origination  to  destination  terminal  in  the 
SETUP  message  described  in  NTU  90-301  (see  Appendix  A)  and  NIU  90-302  (see  Appendix  B). 
The  SETUP  message  is  described  as  sent  to  the  network  and  by  the  network  toward  the  called  user 
to  initiate  call  establishment. 

The  Information  needed  to  carry  the  Calling  Party  Number  is  described  in  a  paragraph  titled 
Calling  Party  Number.  "The  Purpose  of  the  Calling  party  number  information  element  is  to 
identify  the  origin  of  the  call."  The  information  element  may  say  that  the  number  is  not  available, 
the  application  must  be  able  to  handle  this  situation  appropriately. 

7.2.1.5.5.2  Host-Switch  Messages 

The  necessary  function  required  by  this  service  is  die  handling  of  the  incoming  Calling  Party 
Number. 

The  Host  Computer  messages  are  being  described  in  the  ANSI  Switch-Computer  Applications 
Interface  (SCAI)  Working  Document,  T1S1. 1/91-387  (Ref.  [23]).  Section  5  of  the  SCAI  working 
document  described  the  DATA/VOICE  COORDINATION  ASE  "which  may  be  used  by  an 
Application  Process  on  either  a  switch  or  a  computer  to  exchange  information  and  commands  for 
the  purpose  of  coordinating  voice  and  data  services."  The  protocol  definition  is  currently  for 
further  study. 
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Figure  7-15.      Call  Delivery  with  Data  Service  Element  Smart  Terminal/TA 
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7.2.1.6  Call  Back  on  Busy/Abandonment  Service  Element 

In  this  service,  no  agents  are  available  to  receive  an  incoming  call.  The  caller  may  do  any  of  the 
following: 

1.  Receive  Busy  (possible  reasons:  all  agents  busy,  maximum  queue  size), 

2.  Receive  an  Announcement  (i.e.,  "All  Lines  are  Busy,  An  agent  will  call  you  back 
when  one  becomes  available")  followed  by  disconnect, 

3.  be  placed  in  a  queue  (possibly  with  an  announcement  "Wait  for  the  next  available 
agent,  if  you  hangup,  an  agent  will  return  your  call")  for  the  next  available  agent  and 
then  disconnect. 

The  caller's  phone  number  will  be  recorded  so  that  an  agent  can  call  back  later  (see  fig.  7-17). 
This  service  cannot  be  invoked,  unless  the  call  is  delivered  to  the  final  switch. 

The  sequence  of  events  is  as  follows: 

a.  Caller  places  a  call  to  the  phone  number  of  the  "Call  Delivery  service  user"  (800 
number  in  one  user's  application). 

b.  The  calling  line  id  is  recorded  by  a  host  application. 

c.  The  treatment  may  be  busy,  an  announcement  and  disconnect,  or  being  placed  in  a 
queue.  If  the  caller  was  placed  in  a  queue,  they  subsequently  disconnected. 

d.  Agent  obtains  the  number  from  the  application  software  and  places  a  call. 

7.2.1.6.1  User  Environment 

Some  of  the  users'  descriptions  of  the  service  have  specified  a  hardware  and  software  environment 
in  which  the  service  should  work.  At  a  minimum,  the  service  should  work  in  the  following 
environment: 

IBM  3270  type  terminals 
•     An  IBM-compatible  host 
SNA  host  networks. 

These  are  minimum  requirements  and  the  actual  description  of  the  service  is  more  general  in  that 
it  will  work  with  other  terminals,  hosts,  and  networks. 

7.2.1.6.2  Architecture 

Two  architectures  for  this  application  have  been  proposed  and  adopted  (March  1989  and  June  1989 
NIU-Forum).  The  first  architecture  calls  for  the  information  to  be  delivered  to  the  agent's  terminal 
and  the  second  to  a  host  computer.  Only  the  second  architecture  is  considered  here  because  there 
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is  no  mechanism  to  pass  information  about  calls  that  have  never  reached  a  station  (i.e.,  Caller 
disconnects,  PBX  returns  busy)  to  a  station. 

7.2. 1.6  J  Information  Flow 

The  flow  diagrams  show  the  general  information  flow  necessary  to  provide  the  service  described. 
Some  messages  that  are  normally  present  (i.e.,  confirmation  messages,  error  messages,  disconnect) 
are  not  shown  if  they  are  not  necessary  to  explain  the  working  of  the  service. 

The  flow  diagram  for  call  abandonment  can  be  seen  in  figure  7-18.  The  call  setup  information, 
including  Calling  Party  Number  (CPN)  goes  across  the  network.  The  Switch  transmits  the  call 
setup  information  (CPN)  to  the  host  computer.  The  caller  then  "Disconnects"  and  the  host 
computer  is  informed,  so  it  puts  the  number  in  a  list  for  later  callback.  At  a  later  time,  the  agent 
interacts  with  the  host  and  selects  a  callback  number.  The  agent  can  then  either  generate  the  call 
via  the  host  or  dial  the  number  using  the  phone.  Figure  7-19  is  the  flow  diagram  for  the  case 
where  the  caller  receives  busy  or  hears  an  announcement. 

7.2.1.6.4  Network  Signalling  Requirements 

The  network  signalling  requirements  for  this  service  are  the  same  as  for  Call  Delivery  using  the 
Switch  to  Host  interface  (see  fig.  7-16). 

7.2.1.6.5  Protocol  Description 

The  messages  and  protocol  elements  described  below  are  only  those  required  by  the  service  being 
described.  Other  messages  and  protocol  elements  are  not  discussed  if  they  are  not  used  by  the 
application  being  described,  even  through  they  may  be  required  for  other  reasons,  such  as  routing 
of  the  call. 

7.2.1.6.5.1  Call  Setup  User  Information 

The  Customer  identifier  can  be  carried  from  the  origination  to  destination  terminal  in  the  SETUP 
message  described  in  NTU  90-301  (see  Appendix  A)  and  NTU  90-302  (see  Appendix  B).  The 
SETUP  message  is  described  as  sent  by  the  calling  user  to  the  network  and  by  the  network  to  the 
called  user  to  initiate  call  establishment. 

The  Information  needed  to  carry  the  Calling  Party  Number  is  found  in  the  paragraph  titled  Calling 
Party  Number.  "The  purpose  of  the  Calling  party  number  information  element  is  to  identify  the 
origin  of  the  call."  The  information  element  may  say  that  the  number  is  not  available,  the 
application  must  be  able  to  handle  this  situation  appropriately. 

7.2.1.6.5.2  Host-Switch  Messages 

The  necessary  function  required  by  this  service  is  the  handling  of  the  incoming  Calling  Party 
Number. 

The  Host  Computer  messages  are  being  described  in  the  ANSI  Switch-Computer  Applications 
Interface  (SCAI)  Working  Document,  T1S1. 1/91-387  (Ref.  [23]). 
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Figure  7-19.      Call  Back  on  Busy/Abandonment  Service  Element  Information  Row  Diagram  —  Busy. 
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Section  5  of  the  SCAI  working  document  described  the  DATA/VOICE  COORDINATION  ASE 
"which  may  be  used  by  an  Application  Process  on  either  a  switch  or  a  computer  to  exchange 
information  and  commands  for  the  purpose  of  coordinating  voice  services."  The  protocol  is 
currently  for  further  study. 

7.2.1.7  Terminal  Connectivity  Service  Element 

This  service  provides  connectivity  between  a  terminal  and  a  host  using  an  ISDN  link.  This  is 
illustrated  in  figure  7-20. 

The  sequence  of  events  is  as  follows: 

a.  The  user  causes  a  call  to  be  placed  from  the  terminal  to  a  port  on  the 
host/controller.13 

b.  Upon  connection  of  the  call  the  data  transport  protocol  is  initiated. 

c.  When  the  data  session  is  complete  the  call  is  disconnected. 

7.2.1.7.1  User  Environment 

Some  of  the  users'  descriptions  of  the  service  have  specified  a  hardware  and  software  environment 
in  which  the  service  should  work.  At  a  minimum,  the  service  should  work  in  the  following 
environment: 

•     IBM  3270  type  terminals 

An  IBM-compatible  host 

SNA  host  networks. 

These  are  minimum  requirements  and  the  actual  description  of  the  service  is  more  general  in  that 
it  will  work  with  other  terminals,  hosts,  and  networks. 

7.2.1.7.2  Information  Flow 

The  information  flow  diagrams  show  the  data  that  must  be  sent  between  nodes  necessary  to  provide 
the  service  described.  Signalling  messages  that  are  normally  present  (i.e.,  confirmation  messages, 
error  messages,  disconnect)  are  shown  for  simplicity  if  they  are  not  necessary  to  explain  the 
working  of  the  service. 

The  flow  diagram  in  figure  7-21  shows  the  general  information  flow  necessary  to  provide  the 
described  service. 


The  use  of  some  ISDN  features  for  security  (i.e.,  CLID)  may  be  required,  but  are  not  part  of  the 
user  application  description  (text  or  figures). 
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7.2.1.7.3  Network  Protocol  Requirements 

The  network  protocol  requirements  for  this  service  can  be  seen  in  figure  7-20.  As  shown  in  that 
figure,  there  needs  to  be  ISDN  connectivity  between  the  terminal  and  the  point  where  it  is  attached 
to  the  computer  or  controller. 

The  higher  layer  protocols  for  carrying  the  user  data  are  not  described  here.  The  Network 
Interconnectivity  Profile  Team  should  provide  the  higher  level  protocol  specification  when 
completing  Application  Profiles  for  the  User  Application  Requirements  Data  Forms  numbered: 
830008,  830009,  960009  (Refs.  [39,  40,  41]). 

7.2.1.7.4  Protocol  Description 

The  messages  and  protocol  elements  described  below  are  only  those  required  by  the  service  being 
described.  Other  messages  and  protocol  elements  are  not  discussed  if  they  are  not  used  by  the 
application  being  described,  even  through  they  may  be  required  for  other  reasons,  such  as  routing 
of  the  call. 

The  protocol  described  in  NIU  90-301  (see  Appendix  A)  and  NIU  90-302  (see  Appendix  B)  can 
be  used  for  the  setup  and  breakdown  of  the  call  being  made  to  carry  the  data  protocol. 

The  only  information  element  that  may  have  a  direct  bearing  on  the  service  is  in  the  SETUP 
message  described  as  "sent  by  the  calling  user  to  the  network  and  by  the  network  to  the  called  user 
to  initiate  call  establishment."  The  information  element  is  the  Bearer  Capability  Information 
Element.  The  user  can  ask  for  the  appropriate  information  transfer  capability  and  transfer  mode. 


7-28 


NIU-Forum  Agreements  on  ISDN 


7.2.1.8  Protocol  Summary  and  Status 

The  following  is  a  summary  of  the  protocol  requirements  of  the  Incoming  Call  Management 
Application. 

Table  7-2.  Protocol  Requirements  for  Incoming  Call  Management  Application  Profile 


Annlication 
Service  Element 

Protocol  Element 

Document 

Status 

Call  Transfer 

With  Associated  Data 

User — User 

NTU  90—301  &  NIU 
90—302 
Implementation 
Agreements 

See 

Appendices 
B  and  C  of 
this 

document 

Call  Transfer 

T1S1.2/91— 309  (Ref. 
[22])  Proposed 

Protocol 
Definition 

Host — Switch 

T1S1. 1/91— 387  SCAI 
Working  Document, 
(Ref.  [23]) 

Service 
Definition 

Call  Delivery 

With  Associated  Data 

Calling  Party 
Number 

NTU  90—301  &  NTU 
90—302 
Implementation 
Agreements 

See 

Appendices 
B  and  C  of 
this 

document 

Host— Switch 

T1S  1.1/9 1—387  SCAI 
Working  Document 
(Ref.  [23]) 

Service 
Definition 

Terminal  Connectivity 

Bearer  Capability 

NTU  90—301  &  NTU 
90—302 
Implementation 
Agreements 

See 

Appendices 
B  and  C  of 
this 

document 

Higher  Layer 

Network 

Interconnectivity 

Family 

In  Progress 

Call  Back 

Calling  Party 
Number 

NTU  90—301  &  NTU 
90—302 
Implementation 
Agreements 

See 

Appendices 
B  and  C  of 
this 

document 

Host — Switch 

T1S1. 1/91— 387  SCAI 
Working  Document 
(Ref.  [23]) 

Service 
Definition 

Legend  Near  Completion  —  Implementation  Agreements  are  near  completion. 
Protocol  definition  —  The  protocol  is  currently  being  defined. 
Service  definition  —  Ground  work  for  starting  protocol  work  is  being  done. 
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7.2.2  Future  ISDN  CPE  Compatibility/Capability 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  ISDN  CPE 
Compatibility/Capability.  Refer  to  section  7.2.2  of  the  North  American  ISDN  Users'  Forum  (NIU- 
Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication 
1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work  within  the  NIU-Forum. 

7.2.3  Future  ISDN  Network  Interconnectivity 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  ISDN  Network 
Interconnectivity.  Refer  to  section  7.2.3  of  the  North  American  ISDN  Users'  Forum  (NIU-Forum) 
Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  1,  (Ref. 
[32]),  for  information  regarding  the  current  status  of  this  work  within  the  NIU-Forum. 

7.2.4  Future  Messaging  and  Answering 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Messaging  and  Answering. 
Refer  to  section  7.2.4  of  the  North  American  ISDN  Users'  Forum  (NIU-Forum)  Working 
Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  1,  (Ref.  [32]),  for 
information  regarding  the  current  status  of  this  work  within  the  NIU-Forum. 

7.2.5  Future  Bandwidth  Negotiation 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Bandwidth  Negotiation. 
Refer  to  section  7.2.5  of  the  North  American  ISDN  Users'  Forum  (NIU-Forum)  Working 
Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  1,  (Ref.  [32]),  for 
information  regarding  the  current  status  of  this  work  within  the  NIU-Forum. 

7.2.6  Future  Network  Management/ISDN  Administration 

Editor's  Note:  This  section  is  reserved  for  future  agreements  regarding  Network 
Management/ISDN  Administration.  Refer  to  section  7.2.6  of  the  North  American  ISDN  Users' 
Forum  (NIU-Forum)  Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  — 
Publication  1,  (Ref.  [32]),  for  information  regarding  the  current  status  of  this  work  within  the  NIU- 
Forum. 
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[40]      NIU-Forum  User  Application  Requirements  Data  Form  830009,  "Synchronous  Terminal  to 
Controller". 

[41]      NIU-Forum  User  Application  Requirements  Data  Form  960009,  "Asynchronous  Access  to  Host 
Computer". 

8.4  Other  Documents 

[42]      NIST  Special  Publication  500-183,  Stable  Implementation  Agreements  for  Open  Systems 
Interconnection  Protocols,  Version  4,  Edition  1,  December  1990. 

[43]      ISO  9646,  Information  Processing  Systems,  OSI  Conformance  Testing  Methodology  and 
Framework.  Parts  1-5,  1989. 


14    These  documents  are  available  by  contacting  the  NIU-Forum  Administrator,  NIST,  Building  222 . 
Room  B364,  Gaithersburg,  MD  20899. 
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NIU  90-301 
Implementation  Agreement 
of  the  North  American  ISDN  Users'  Forum 

Layer  3  Signalling  Specification  for  the 
Minimal  Set  of  Circuit-Switched  Bearer  Services  for 
the  ISDN  Basic  Rate  Interface/Class  I. 

Baseline  Text 

American  National  Standard  Tl.607-1990: 
Integrated  Services  Digital  Network  (ISDN)  — 
Layer  3  Signalling  Specification  for 
Circuit-Switched  Bearer  Service  for 
Digital  Subscriber  Signalling  System  Number  1  (DSS1). 

Base  Standards 
CCITT  Recommendation  Q.931  (1988): 
ISDN  User-Network  Interface  Layer  3  — 
Specification  For  Basic  Call  Control. 

ANSI  Tl.607-1990 
ANSI  T1.604*: 

Integrated  Services  Digital  Network  (ISDN)  — 
Minimal  Set  of  Bearer  Services  for 
the  Basic  Rate  Interface. 


A.l  Abstract 

This  Implementation  Agreement  specifies  procedures  for  establishing,  maintaining,  and  clearing  connections  at  the 
Integrated  Services  Digital  Network  (ISDN)  user-network  interfaces  and  are  mandatory  for  the  support  of  the  minimal 
set  of  circuit-switched  bearer  services  specified  by  ANSI  Tl. 604- 1990*  Integrated  Services  Digital  Network  (ISDN) 

—  Minimal  Set  of  Bearer  Services  for  the  Basic  Rate  Interface,  (Ref.  [15]).  Procedures  for  circuit-mode  digital, 
circuit-mode  speech  and  circuit-mode  voiceband  data  bearer  services  are  as  specified  in  the  baseline  text  ANS 
Tl.607-1990,  Integrated  Services  Digital  Network  (ISDN)  — Digital  Subscriber  Signalling  System  Number  1  (DSS1 ) 

—  Layer  3  Signalling  Specification  for  Circuit-Switched  Bearer  Service,  (Ref.  [17])  as  further  resolved  by  this 
agreement.  The  packet-mode  data  service  is  included  in  this  document  as  a  bearer  service.  Procedures  for  the 
packet-mode  bearer  service  will  be  detailed  in  another  document. 


Subject  to  further  discussion. 
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A.2  Introduction 


The  original  implementation  agreement  (NIU  90-301)  was  reached  by  marking  up  the  text  of  ANS  T 1.607- 1990, 
(Ref.  [17])  to  reflect  the  clarifications  of  text  and  selection  of  options.  This  appendix  translates  the  implementation 
agreement  markup  into  a  listing  of  these  clarifications  and  selections,  (i.e.,  this  appendix  lists  the  differences  [the 
"delta"]  between  the  implementation  agreement  marked  up  ANS  Tl.607-1990,  and  the  original  text  of  ANS  T1.607- 
1990). 

A.3  NIU  90-301  Delta  List" 

The  IA  has  adopted  the  ANS  Tl.607-1990*"  (Ref.  [17])  standard  with  the  following  clarifications  of  the  text,  and 
selection  of  options: 


ANS  Tl.607-1990 
SECTION/TABLE  NUMBER/NAME 


Section  1 
General 

Section  1.1 
Scope  and  Purpose 

Section  2.2 

States  associated  with  the  global  reference 
call 

Section  3 

Message  functional  definition  and  content 
Item  (b),  Subitem  (2) 

Section  3.1 

Messages  for  circuit-mode  connection  control 
Table  1  —  Messages  for  circuit-mode  connection 
control 

Section  3.1 

Messages  for  circuit-mode  connection  control 
Table  1  —  Messages  for  circuit-mode  connection 
control 


IMPLEMENTATION  AGREEMENTS  - 
CLARIFICATION  OF  TEXT  AND 
SELECTION  OF  OPTIONS 

Delete  "1.  General"  heading. 

Replace  this  section  with  Attachment  A  of  this 
document. 

Delete  this  section  including  subsections. 


Delete  last  sentence  from  the  Note:  "Annex  D 
contains  a  description  of  the  information  element 
usage  for  symmetric  NT2-NT2  interfaces." 

Change  "NOTIFY  3.1.7"  to  "*NOTTFY". 


Add  the  following  footnote  below  table  1:  "*  See 
section  5.8.4  for  treatment  of  this  message." 


Note  that  this  Delta  List  was  developed  in  "good  faith"  by  NIST  as  a  simple  equivalent  representation  of 
the  actual  agreements.  It  has  been  reviewed  and  approved  by  the  editors  of  the  Signalling  Working  Group 
as  per  recommendation  of  the  Executive  Steering  Committee. 

This  documents  can  be  purchased  from:  American  National  Standards  Institute,  1 1  West  42nd  Street  New 
York,  NY  10036. 
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Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 


Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 


Change  the  "Channel  Identification/Direction"  cell 
from  "both  (Note  1)"  to  "u  ->  n". 


Change  the  "Channel  Identification/Length"  cell  from 
"2-*"  to  "2-3". 


Change  the  "Progress  Indicator/Direction"  cell  from 
"both"  to  "n  ->  u". 


Change  the  "Progress  Indicator/Length"  cell  from 
"2-4"  to  "2,4". 


Delete  "Display"  row. 


Delete  Notes  1,  4,  5. 


Delete  the  last  sentence  from  Note  3. 


Change  Note  "6  Included  if  the  network  optionally 
provides  additional  information  describing  tones."  to 
"6  The  network  will  always  provide  this  IE." 

Change  the  "Channel  Identification/Length"  cell  from 
"2-*"  to  "2-3". 


Delete  reference  to  "Note  2"  in  the  "Progress 
indicator/Type"  cell. 


Change  the  "Progress  Indicator/Length"  cell  from 
"2-4"  to  "2,  4". 


Delete  "Display"  row. 
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Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 


Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 


Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 
Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 


Delete  Notes  2,  3,  4. 


Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 


Change  the  "Channel  Identification/Direction"  cell 
from  "both  (Note  1)"  to  "u  ->  n  (Note  1)". 


Change  the  "Channel  Identification/Length"  cell  from 

"2-*"  to  "3". 


Change  the  "Progress  indicator/Direction"  cell  from 
"both"  to  "n  ->  u". 


Change  the  "Progress  Indicator/Length"  cell  from  "2- 
4"  to  "2,  4". 


Delete  the  following  rows: 

•  "Display"; 

•  "Connected  number"; 

•  "Connected  subaddress"; 

•  "Low  Layer  compatibility". 

Change  Note  1  from  "Included  in  the  network-to-user 
direction  for  support  of  the  procedures  in  Annex  D." 
to  "The  coding  of  this  IE  should  be  always  'Exclusive 
B'." 

Delete  the  following  from  Note  3:  "or  in  connection 
with  the  provision  of  in-band  tones  and  patterns." 

Delete  Notes  4,  5,  7,  8,  9. 


Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 
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Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 


Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 


Delete  "Display"  row. 


Delete  Notes  1,  2. 


Change  Note  3  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  if  the  network  is  required  to  turn 
Alerting  off." 

Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 


Change  the  "Cause/Length"  cell  from  "4-32"  to  "4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Connected  Number"; 

•  "Connected  subaddress". 

Delete  Notes  1,  2,  4,  5. 


Change  Note  3  to:  "Included  if  the  network  must 
turn  tones  on  or  off,  or  turn  ALERTING  off." 


Change  the  "Call  Reference/Length"  cell  from 
"2-*"  to  "2-3". 


Delete  "Display"  row. 


Change  the  "Keypad  Facility/Length"  cell  from 
"2-34"  to  "3-34". 


Delete  Notes  2,  3. 
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Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 


Add  the  following  to  the  end  of  Note  4  ("The  Keypad 
facility  information  element.."):  "When  INFO  is  sent 
u  ->  n,  this  IE  must  be  present." 

Change  Note  5  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  if  the  network  is  required  to  turn 
tones  off." 


Section  3.1.7 
NOTIFY 


Delete  this  section. 


Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 


Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 


Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 


Change  "Direction"  in  table  header  from  "both"  to 
"n  ->  u". 


Change  the  "Direction"  cell  in  the  following  rows 
from  "both"  to  "n  ->  u": 

•  "Protocol  discriminator"; 

•  "Call  reference"; 

•  "Message  type"; 

•  "Cause"; 

•  "Progress  Indicator". 

Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Length"  cell  from 
"2-32"  to  "2,4-10". 


Delete  "Display"  row. 


Delete  Notes  2,  3. 


Change  Note  4  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  when  tones  or  some 
announcement  are  provided  in-band." 

Change  the  "Call  reference/Length"  cell  from  "2-*" 
to  "2-3". 
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Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 


Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 


Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 

Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 

Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Change  the  "Cause/Length"  cell  from  "2-32"  to  "2,4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Connected  number"; 

•  "Connected  subaddress". 

Delete  Notes  3,  4,  6,  7. 


Change  Note  5  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  if  the  network  must  turn  tones  or 
Alerting  off." 

Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Length"  cell  from  "2-32"  to  "2, 4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Connected  number" 

•  "Connected  subaddress". 

Delete  Notes  3,  4,  6,  7. 


Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Change  Note  5  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  if  the  network  is  required  to  turn 
tones  on  or  off." 

Change  the  "Call  Reference/Length"  cell  from 
"2-*"  to  "2-3". 


Delete  the  following  rows: 

•  "Repeat  Indicator"; 

•  "Network-Specific  Facilities"; 

•  "Display". 
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Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 
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Delete  from  the  "Bearer  Capability/Type"  cell  the 
reference  to  Note  2. 


Change  the  "Bearer  Capability/Length"  cell  from 
"4-13"  to  "4-8". 


Change  the  "Channel  Identification/Length"  cell  from 
"2-*"  to  "2-3". 


Change  the  "Progress  Indicator/Direction"  cell  from 
"both"  to  "n  ->  u". 


Change  the  "Progress  Indicator/Length"  cell  from 
"2-4"  to  "2,4". 


Change  the  "Calling  party  number/Length"  cell  from 
"2-*"  to  "2-19". 


Change  the  "Called  party  address/Length"  cell  from 
"2-*"  to  "2-18". 


Change  the  "Transit  Network  Selection/Length"  cell 
from  "2-*"  to  "2-7". 


Change  the  "Higher  Layer  Compatibility/Length"  cell 
from  "2-4"  to  "2-5". 


Delete  Notes  1,  2,  5,  6,  7. 


Add  to  the  end  of  Note  8:  "The  digits  in  this  EE  are 
0  to  9,  *,  and  #." 


Change  Note  9  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "The  network  will  always  provide  this  IE." 

Add  to  the  end  of  Note  13:  "The  network  should 
transport  this  IE  transparently.  This  EE  is  optional  on 
the  user  side." 
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Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Add  to  the  end  of  Note  15:  "The  network  should 
transport  this  IE  transparently.  This  IE  is  optional  on 
the  user  side.  The  total  length  is  2  to  16  octets." 

Add  to  the  end  of  Note  16:  "The  network  should 
transport  this  IE  transparently.  This  IE  is  optional  on 
the  user  side." 

Add  to  the  end  of  Note  17:  "The  network  will  treat 
this  IE  on  sending  and  receiving  as  described  in  the 
User-User  supplementary  service  Implementation 
Agreement." 

Delete  "and  7kHz  audio"  from  Note  20. 


Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 


Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Change  the  "Channel  Identification/Type"  cell  from 
"M"  to  "M*". 


Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Add  the  following  footnote  before  Note  1:  "*  The 
coding  of  the  channel  ID  should  always  be  'Exclusive 
B'." 


Section  3.1.12  Change  the  "Channel  Identification/Length"  cell 

SETUP  ACKNOWLEDGE  from  "3-*"  to  "3". 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Section  3.1.12  Change  the  "Progress  Indicator/Length"  cell  from  "2- 

SETUP  ACKNOWLEDGE  4"  to  "2,4". 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Section  3.1.12  Delete  "Display"  row. 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Change  Note  1  to:  "The  only  valid  value  for  progress 
indicator  is  8  (refer  to  section  4.5.21  octet  4). 
Included  in  connection  with  the  provision  of  in-band 
information/patterns. " 
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Section  3.1.12  Delete  Notes  2,  3. 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 

Section  3.1.13 
STATUS 


Change  Note  4  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones  (e.g.,  activate  dial  tone)."  to  "Included  if  the 
network  is  required  to  turn  on  dial  tone." 

Change  the  first  sentence  from  "This  message  is  sent 
by  the  user  or  the  network  in  response  to  a  STATUS 
ENQUIRY  message  or  at  any  time  during  a  call  to 
report  certain  error  conditions  as  listed  in  5.8."  to 
"This  message  is  sent  by  the  user  in  response  to  a 
STATUS  ENQUIRY  message  sent  by  the  network,  or 
by  either  the  user  or  the  network  to  report  certain 
error  conditions  as  listed  in  5.8." 


Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Change  the  "Call  Reference/Length"  cell  "2-*"  to  "2- 
3". 


Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Change  the  "Cause/Length"  cell  from  "4-32"  to  "4- 
10". 


Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Delete  "Display"  row. 


Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Delete  Notes  1,  2. 


Section  3.1.14 
STATUS  ENQUIRY 


Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 


Change  "This  message  is  sent  by  the  user  or  the 
network  at  any  time  to  solicit  a  STATUS  message 
from  the  peer  layer  3  entity."  to  "This  message  is  sent 
by  the  network  during  the  active  state  to  solicit  a 
STATUS  message  from  the  peer  layer  3  entity." 

Change  "Direction"  in  the  table  header  from  "both"  to 
"n  ->  u". 


Change  the  "Direction"  cell  in  the  following  rows 
from  "both"  to  "n  ->  u": 

•  "Protocol  discriminator"; 

•  "Call  reference"; 

•  "Message  type". 
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Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 


Change  "Call  Reference/Length"  cell  from  "2-*"  to 
"2-3". 


Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 
Section  3.2 

Messages  used  with  the  global  call  reference 
Section  4.2 

Protocol  Discriminator 


Section  4.2 

Protocol  Discriminator 

Figure  2  —  Protocol  Discriminator 

Section  4.2 

Protocol  Discriminator 

Table  19  —  Protocol  Discriminator 

Section  4.3 
Call  Reference 


Section  4.3 
Call  Reference 

Section  4.3 
Call  Reference 


Section  4.3 
Call  Reference 

Section  4.3 
Call  Reference 

Section  4.4 

Message  Type 

Table  20  —  Message  types 


Delete  "Display"  row. 


Delete  Notes  1,  2. 


Delete  this  section  including  subsections. 

Add  the  following  paragraph  after  the  second 
paragraph.  "The  only  value  supported  for  call  control 
messages  is  described  below,  in  Figure  2." 

Change  "ANSI  T1.607"  to  "Q.931". 


Change  "ANSI  T1.607"  to  "Q.931"  in  the  row  labeled 
"0000  1000". 


Change  the  first  sentence  of  the  third  paragraph  from 
"...  for  a  basic  user-network  interface,  and  a  call 
reference  value  of  two  octets  for  a  primary  rate 
interface."  to  "and  a  maximum  of  2.  The  network 
will  send  one  octet  call  reference  value  (CRV)  unless 
all  127  available  codepoints  are  occupied." 

Delete  the  fourth  paragraph  "As  a  network  option  ... 
one  or  two  octets." 

Add  "The  Dummy  Call  Reference  and  the  Global  Call 
Reference  are  not  supported  for  BRI/Class  I  circuit- 
switched  calls."  after  figure  5. 

Delete  the  last  sentence  from  the  eighth  paragraph 
"The  call  reference  ...  (e.g.,  Restart  procedures)." 

Delete  Note  2  ("The  numerical  value  ...  defined  in 
3.2."). 

Add  an  asterisk  (*)  to  the  beginning  of  the  "NOTIFY" 
row. 
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Section  4.4 

Message  Type 

Table  20  —  Message  Types 

Section  4.5.1 
Coding  Rules 

Section  4.5.1 
Coding  Rules 

Figure  7  —  Formats  of  information  elements 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 


Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 


Add  as  a  footnote  "*  See  section  5.8.4  for  treatment 
of  this  message  type." 

Delete  the  last  3  sentences  of  the  fourth  paragraph 
"Two  types  of  ...  octet  elements." 

Delete  Figure  7  (b).  Single  octet  information  element 
format  (type  2). 


Delete  "Repeat  Indicator"  row. 


Delete  reference  to  Note  6  in  row  "Bearer  capability". 


Change  the  "Bearer  capability/max  length"  cell  from 
"13"  to  "8". 


Change  the  "Cause/max  length"  cell  from  "32"  to 
"10". 


Change  the  "Cause/max.  no.  of  occurrences"  cell  from 
"3"  to  "2". 


Change  the  "Channel  identification/max  length"  cell 
from  "(Note  4)"  to  "3". 

Delete  the  following  rows: 

•  "Network-specific  facilities"; 

•  "Notification  indicator"; 

•  "Display"; 

•  "Connected  number"; 

•  "Connected  subaddress". 

Change  the  "Calling  Party  Number/max  length"  cell 
from  "(Note  4)"  to  "19". 


Change  the  "Called  Party  Number/max  length"  cell 
"(Note  4)"  to  "18". 
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Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 


Delete  reference  to  Note  2  in  the  "Transit  Network 
selection"  row. 


Change  the  "Transit  Network  selection/max  length" 
cell  from  "(Note  4)"  to  "7". 


Delete  "4"  from  the  "Transit  Network  Selection/max. 
no.  of  occurrences"  cell. 


Delete  the  following  rows: 

•  "Restart  indicator"  and 

•  "Escape  for  extension". 

Delete  Notes  3,  4,  and  6. 


Section  4.5.1 
Coding  Rules 

Figure  8  —  Information  element  format  using  escape 
for  extension 


Delete  this  figure. 


Section  4.5.2 
Extensions  of  codesets 


Change  "T1.608"  to  "NIU  89-320"  in  the  first  bullet 
in  the  fourth  paragraph. 


Section  4.5.2 
Extensions  of  codesets 


Change  the  ninth  paragraph  to:  "Codeset  7 
information  elements  shall  be  handled  according  to 
the  procedures  for  unrecognized  information  elements 
(see  5.8.7.1)  by  the  first  exchange." 


Section  4.5.2 
Extensions  of  codesets 

Section  4.5.3 

Locking  shift  procedure 

New  codeset  identification  coding 

Section  4.5.4 

Non-locking  shift  procedures 
Section  4.5.4 

Non-locking  shift  procedures 
Temporary  codeset  identification  coding 

Section  4.5.4 

Non-locking  shift  procedures 
Temporary  codeset  identification  coding 


Delete  the  tenth  paragraph  ("Codeset  6  ...  bilateral 
agreements."). 

Change  "T1.608"  to  "NIU  89-320"  in  row  "codeset 
5". 


Delete  "(a)  process  the  non-locking  ...  below."  from 
the  second  paragraph. 

Change  "T1.607"  to  "NIU  90-301"  in  row  "codeset 
0". 


Change  "T1.608"  to  "NIU  89-320"  in  row  "codeset 
5". 
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Section  4.5.5 
Bearer  capability 

Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 


Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  capability 


Section  4.5.5 
Bearer  capability 

Information  transfer  capability  (octet  3)  coding 

Section  4.5.5 
Bearer  capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  capability 

Information  transfer  rate  (octet  4)  coding 

Section  4.5.5 
Bearer  capability 

Information  transfer  rate  (octet  4)  coding 


In  the  second  paragraph  change  "13  octets"  to  "8 
octets". 

Change  octet  4,  bit  8  from  "0/1"  to  "1". 


Delete  octets 

•  4a*; 

•  4b*; 

•  5b*  Note  2; 

•  5b*  Note  3; 

•  5c*; 

•  5d*. 

Change  octet  5a*,  bit  8  from  "0/1"  to  "1". 


Delete  Notes  1,  2,  and  3. 


Delete  "or  V.120"  from  the  end  of  Note  4. 


Add  the  following  after  Figure  11:  "Octets  6  and  7 
are  included  for  information  only  and  shall  not  be 
used  for  circuit-switched  calls.  The  coding  and 
application  for  these  octets  are  included  in  another 
document." 

Delete  row  "10001  7  kHz  audio". 


Change  the  title  to  "Information  transfer  rate  (octet 
4)". 


Delete  the  following  rows: 

•  "10011  384kbit/s"; 

•  "10100  1472  kbit/s  (see  Note  2)"; 

•  "10101  1536  kbit/s". 

Change  Note  1  to:  "The  bearer  capability  is 
bidirectional  symmetric  at  the  information  transfer 
rate  specified  in  octet  4." 
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Section  4.5.5 
Bearer  capability 

Information  transfer  rate  (octet  4)  coding 

Section  4.5.5 
Bearer  capability 

Section  4.5.5 
Bearer  capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  capability 

Synchronous/asynchronous  (octet  5a)  coding 

Section  4.5.5 
Bearer  capability 

Synchronous/asynchronous  (octet  5a)  coding 

Section  4.5.5 
Bearer  capability 
Negotiation  (octet  5a)  coding 

Section  4.5.5 

Bearer  capability 

User  rate  (octet  5a)  coding 

Section  4.5.5 
Bearer  capability 


Section  4.5.5 
Bearer  capability 


Section  4.5.6 
Call  state 

Global  interface  state  value  (octet  3)  coding 


Delete  Note  2. 


Delete  the  codings  of  octets  4a  (structure, 
configuration,  establishment)  and  4b  (symmetry). 

Delete  "and  optionally  octets  5b,  5c,  and  5d  as 
defined  below."  from  row  "00001". 


Delete  "and  G.725  7  kHz  audio"  from  row  "00101". 


Delete  rows  "00111"  and  "01000". 


Delete  Note  2. 


Delete  row  "1  asynchronous". 


Delete  the  second  and  third  sentences  from  the  Note. 


Delete  row  "1  In-band  negotiation  possible". 


Delete  all  code  points  except  "01111  56  kbit/s 
CCrTT  Recommendation  V.6." 


Delete  all  text  relating  to  octet  5b  (i.e.,  sections 
labeled  "Octet  5b  for  CCITT  Recommendation  V.  100 
or  X.30  rate  adaption"  and  "Octet  5b  for  CCITT 
Recommendation  V.120  rate  adaption"). 

Delete  all  tables  and  text  referring  to  octets  5c 
(number  of  data  bits  excluding  parity  bit,  parity 
information)  and  5d  (duplex  mode,  modem  type). 

Delete  this  coding. 


NIU-Forum  Agreements  On  ISDN 


A-15 


Section  4.5.7 
Called  party  number 

Section  4.5.7 

Called  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.7 
Called  party  number 

Section  4.5.7 
Called  party  number 

Numbering  plan  identification  (octet  3)  coding 


Change  the  second  paragraph  to:  "The  maximum 
length  of  this  information  element  is  18  octets." 

Delete  the  following  rows: 

•  "Oil  network  specific  number  (see  Note  4)"  and 

•  "111  reserved  for  extension". 

Delete  Note  4. 


Delete  the  following  rows: 

"0011    Data    numbering    plan  (CCITT 
Recommendation  X.121)"; 

"0100      Telex    numbering   plan  (CCITT 
Recommendation  F.69)"; 
•  "1111  Reserved  for  extension" . 


Section  4.5.7 
Called  party  number 


Section  4.5.9 
Calling  party  number 


Add  Attachment  B  of  this  document  after  the 
following: 

"Number  digits  (octets  4,  etc.) 

This  field  is  coded  with  ASCII  characters, 
according  to  the  formats  specified  in  the  appropriate 
numbering  and  dialing  plan." 

Change  the  second  paragraph  from:  "The  maximum 
length  of  this  information  element  is  network 
dependent."  to  "The  maximum  length  of  this 
information  element  is  19  octets." 


Section  4.5.9 

Calling  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.9 

Calling  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.9 
Calling  party  number 

Numbering  plan  identification  (octet  3)  coding 


Delete  the  following  rows: 

•  "011  network  specific  number  (see  Note  4)"  and 

•  "111  reserved  for  extension". 

Delete  Note  4. 


Delete  the  following  rows: 

"0100      Telex  numbering 
Recommendation  F.69)"  and 
•  "1111  Reserved  for  extension". 


plan  (CCITT 


Section  4.5.9  Add  Attachment  C  of  this  document  after  the 

Calling  party  number  following: 

"Number  digits  (octets  4,  etc.) 

This  field  is  coded  with  ASCII  characters, 
according  to  the  formats  specified  in  the  appropriate 
numbering  or  dialing  plan." 
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Section  4.5.10 

Calling  party  subaddress 


Section  4.5.11 
Cause 


Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Recommendation  (octet  3a)  coding 

Section  4.5.11 
Cause 


Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 


Add  a  new  paragraph  at  the  end  of  the  section:  "In 
the  network  to  user  direction  (n  — >  u),  the  coding 
and  delivery  of  this  IE  depends  on  the  definition  of 
the  Calling  Line  ID  service." 

Change  the  second  sentence  of  the  first  paragraph 
from  "The  maximum  length  of  this  information 
element  is  32  octets."  to  "The  maximum  length  of  this 
information  element  is  10  octets." 

Change  octet  3,  bit  8  from  "0/1"  to  "1". 


Delete  octet  3a*. 


Delete  the  Note. 


Delete  this  coding  and  its  associated  Notes  1  and  2. 


Add  the  following  sentence  to  the  end  of  the 
paragraph  under  "Diagnostics  (octet  5)":  "If  more 
than  one  IE  is  identified  in  a  diagnostic,  they  should 
be  ordered  as  IE's  normally  appear  in  a  message." 

Change  the  "diagnostics"  cell  of  the  first  three  code 
points  to  "Not  used". 


Change  the  "Normal  call  clearing/diagnostics"  cell 
from  "(see  Note  12)"  to  "Not  used". 


Add  to  the  "User  busy/diagnostics"  cell:  "(see  Note 
10)" 


Change  the  "call  rejected/diagnostics"  cell  from  "(see 
Note  12,  user  supplied  diagnostic)  (see  Note  4)"  to 
"Not  used". 

Delete  row  "Number  changed". 
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Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 


Add  "(see  Note  10)"  to  the  "Network  out  of 
order/diagnostics"  cell. 


Add  "(see  Note  10)"  to  the  "Requested  circuit  or 
channel  not  available/diagnostics"  cell. 


Delete  row  "Quality  of  service  unavailable". 


Change  the  "Requested  facility  not  subscribed/ 
diagnostics"  cell  from  "Facility  identification  (see 
Note  1)"  to  "Not  used". 

Change  the  "Bearer  capability  not  authorized/ 
diagnostics"  cell  from  "(see  Note  3)"  to  "Not  used". 


Delete  row  "Bearer  capability  not  presently  available". 


Delete  row  "Service  or  option  not  available, 
unspecified". 


Change  the  "Bearer  capability  not  implemented/ 
diagnostics"  cell  from  "(see  Note  3)"  to  "Not  used". 


Delete  row  "Channel  type  not  implemented". 


Change  the  "requested  facility  no  implemented/ 
diagnostics"  cell  from  "Facility  identification  (see 
Note  1)"  to  "Not  used". 

Delete  rows  "Only  restricted  digital  information 
bearer  capability  is  available"  and  "Service  or  option 
not  implemented,  unspecified". 

Delete  row  "Identified  channel  does  not  exist". 


Change  the  "incompatible  destination/diagnostics"  cell 
from  "Incompatible  parameter  (see  Note  2)"  to  "Not 
used". 
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Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 

Figure  18  —  Coding  of  the  diagnostic  field  for  causes 
57,  58  and  65 

Section  4.5.12 
Channel  identification 
Figure  19  —  Channel 
element 

Section  4.5.12 
Channel  identification 
Figure  19  —  Channel  identification  information 
element 

Section  4.5.12 
Channel  identification 
Interface  identifier  present  (octet  3)  coding 

Section  4.5.12 
Channel  identification 
Interface  identifier  present  (octet  3)  coding 

Section  4.5.12 
Channel  identification 
Interface  type  (octet  3)  coding 

Section  4.5.12 
Channel  identification 
Interface  type  (octet  3)  coding 

Section  4.5.12 
Channel  identification 

Information  channel  selection  (octet  3)  coding 

Section  4.5.12 
Channel  identification 


Delete  row  "Invalid  message,  unspecified". 

Change  the  "Recovery  on  timer  expiry/diagnostics" 
cell  from  "Timer  number  (see  Note  9)"  to  "Not  used". 

Delete  Notes  2,  3,  4,  5,  7,  9,  11,  12. 

Delete  Figure  18  and  text  for  octets  5,  5a,  and  5b. 


Delete  Notes  1,  2,  3,  4. 


Delete  row  "1  Interface  explicitly  ...  with  octet  3.1." 


Delete  the  Note  and  the  reference  to  it  in  row  "0 
Interface  implicitly  identified". 


Delete  row  "1  other  interface:  ...  (see  Note)". 


Add  the  following  after  Note  3:  "4  The  combination 
of  'Any  Channel'  (bits  1,2),  and  'Exclusive'  (bit  4)  is 
invalid." 

Delete  the  text,  codings,  and  figures  relating  to  octets 
3.1,  3.2,  and  3.3. 


Delete  the  octets  3.1,  3.2,  and  3.3. 

identification  information 


Delete  the  Note. 
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Section  4.5.13 
Connected  Number 


Delete  this  section. 


Section  4.5.14 
Connected  subaddress 

Section  4.5.15 
Display 

Section  4.5.16 

High  layer  compatibility 


Section  4.5.18 

Low  layer  compatibility 

Section  4.5.18 

Low  layer  compatibility 

Negotiation  indicator  (octet  3a)  coding 

Section  4.5.18 

Low  layer  compatibility 

Negotiation  indicator  (octet  3a)  coding 

Section  4.5.18 

Low  Layer  compatibility 

User  information  layer  3  protocol  (octet  7)  coding 

Section  4.5.19 
Network-specific  facilities 

Section  4.5.20 
Notification  Indicator 

Section  4.5.21 
Progress  indicator 

Progress  description  (octet  4)  coding 

Section  4.5.21 
Progress  indicator 

Progress  description  (octet  4)  coding 

Section  4.5.22 
Repeat  indicator 

Section  4.5.23 
Restart  indicator 


Delete  this  section. 


Delete  this  section. 


Change  the  second  paragraph  from  "The  maximum 
length  of  this  information  element  is  four  octets."  to 
"The  maximum  length  of  this  information  element  is 
five  octets." 

Delete  the  second  paragraph. 

Delete  row  "1  Out-band  negotiation  possible". 


Delete  Note  1. 


Change  "ANSI  T1.607"  to  "NTU  90-301"  in  row 
"00010". 


Delete  this  section. 


Delete  this  section. 


Delete  row  "000  0100  4  call  has  returned  to  the 
ISDN." 


Add  the  following  after  Note  2:  "3  In  the  SETUP 
message,  n  ->  u,  one  of  two  values  may  be  used:  1  or 
3." 

Delete  this  section. 


Delete  this  section. 
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Section  4.5.24 
Signal 

Figure  32  —  Signal  information  element 

Section  4.5.24 
Signal 

Signal  value  (octet  3)  coding 


Section  4.5.25 

Transit  network  selection 


Section  4.5.25 

Transit  network  selection 


Section  4.5.25 

Transit  network  selection 

Type  of  network  identification  (octet  3)  coding 

Section  4.5.25 

Transit  network  selection 

Network  identification  plan  (octet  3)  coding 

Section  4.5.26 
User-user 


Section  4.5.26 
User-user 

Protocol  discriminator  (octet  3)  coding 

Section  4.6.1 

Operator  system  access 

type  of  access  (octet  3)  coding 

Section  5 

Circuit-switched  call  control  procedures 
Section  5 

Circuit-switched  call  control  procedures 
Section  5.1 

Call  establishment  at  the  originating  interface 


Add  below  the  figure:  "Note  In  the  n  ->  u  direction, 
and  in  the  absence  of  supplementary  services,  the 
public  network  will  offer  signalling  pattern  0  only." 

Delete  the  following  rows: 

•  "intercept  tone  on"; 

•  "answer  tone  on"; 

•  "off  hook  warning  tone  on"; 

•  "ALERTING  on  —  pattern  5"; 

•  "ALERTING  on  —  pattern  6"; 

•  "ALERTING  on  —  pattern  7". 

Change  the  second  sentence  of  the  first  paragraph  to: 
"The  transit  network  selection  information  element 
should  not  be  repeated  in  a  message  (See  Annex  C)." 

Change  the  second  paragraph  to:  "The  default 
maximum  length  of  mis  information  element  is  7 
octets." 

Delete  row  "Oil  international  network  identification". 


Delete  row  "0011  Data  network  identification  code 
(CCITT  Recommendation  X.121)". 

Add  the  following  sentence  to  the  end  of  the  Note 
(after  the  second  paragraph):  "This  IE  is  included 
based  on  user-user  supplementary  service  description 
and  user  application." 

Change  "ANSI  T1.607"  to  "NTU  90-301"  in  row 
"0000  1000". 


Delete  row  "10  private/principal". 


Delete  the  fourth  paragraph  ("As  a  general  principle, 
..."). 

Delete  the  last  sentence  of  second  Note  ("Display 
information  ...  network  to  user."). 

Change  "ANSI  T1.602"  to  "NTU  89-210"  in  the  last 
sentence  of  the  first  paragraph. 
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Section  5.1.3 
Overlap  sending 


Add  the  following  at  the  end  of  section  5.1.3: 
"However,  as  an  option,  the  network  can  determine 
that  a  potentially  complete  code  has  been  received 
following  the  receipt  of  address  information,  and  the 
network  could  use  critical  interdigit  timing  (instead  of 
T302)  to  determine  whether  additional  digits  are 
following.  This  timing  could  be  3-5  seconds.  If 
implemented,  when  this  timer  expires,  a  complete 
address  is  assumed  and  the  procedures  in  Sec.  5.1.5.2 
shall  be  followed.  In  an  INFORMATION  message  is 
received  and  the  critical  interdigit  timing  is  running, 
it  shall  be  stopped." 


Section  5.1.4 

Invalid  call  information 


Delete  the  following  line  from  the  last  paragraph: 
"22  'number  changed';". 


Section  5.1.4 

Invalid  call  information 


Add  the  following  two  paragraphs  to  the  end  of 
section  5.1.4: 

"The  network  should  reject  the  call  request  if  the 
SETUP  message  contains  the  keypad  information 
element,  and  any  of  the  following  information 
elements:  transit  network  selection,  called  party 
number,  or  operator  system  access.  In  this  case,  the 
network  should  send  the  calling  user  equipment  a 
RELEASE  COMPLETE  message  containing  cause  28, 
'invalid  number  format  (location:  public  network 
serving  the  local  user).'". 


"If  the  network  receives  a  called  party  number 
information  element  containing  more  address  digits 
than  expected,  as  determined  by  the  'type  of  number 
and  numbering  plan  identification'  field,  the  network 
should  discard  the  superfluous  digits  and  route  the 
call.  Similarly,  if  the  transit  network  selection 
information  element  contains  more  address  digits  than 
expected,  as  determined  by  the  'type  of  network 
identification'  and  'network  identification  plan'  fields, 
the  network  should  discard  the  superfluous  digits  and 
route  the  call.  If  the  network  receives  a  keypad 
information  element  containing  more  address  digits 
than  required  for  completion  of  digit  analysis,  the 
network  should  discard  the  superfluous  digits 
(according  to  the  network  dialing  plan)  and  route  the 
call.  If  any  of  these  events  occur,  the  local  public 
network  should  send  the  calling  user  equipment  a 
STATUS  message  containing  National-specific  cause 
11,  'More  digits  received  than  allowed:  call  is 
proceeding  (location:  public  network  serving  the  local 
user'  and  the  call  state  information  element  coded  as 
call  state  1,  'call  initiated.'  Private  networks  may 
support  this  procedure,  optionally." 
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Section  5.1.5.1 

Call  proceeding,  en-bloc  sending 


Delete  causes  "58  'bearer  capability  not  presently 
available';"  and  "63  'service  or  option  not  available, 
unspecified';"  from  the  second  paragraph. 


Section  5.1.5.1 

Call  proceeding,  en-block  sending 
Section  5.1.5.2 

Call  proceeding,  overlap  sending 
Section  5.1.5.2 

Call  proceeding,  overlap  sending 
Section  5.1.5.2 

Call  proceeding,  overlap  sending 


Add  to  the  second  paragraph  after  "57 
"34  'no  circuit  or  channel  available';". 


authorized": 


Delete  "58  ...available"  and  "63  ...  unspecified"  from 
the  first  paragraph. 

Add  after  "57  ...  not  authorized":  "34  'no  circuit  or 
channel  available';"  in  the  first  paragraph. 

Add  the  following  at  the  end  of  section  5.1.5.2: 

"Other  Misdialing  Treatments 

The  Network  should  be  capable  of  recognizing  several 
types  of  misdialing.  If  network-provided  tones  and 
announcements  do  not  apply,  the  network  should 
initiate  call  clearing  in  response  to  a  misdialing  error. 
If  en-bloc  sending  has  been  used,  the  network  should 
send  a  RELEASE  COMPLETE  message  to  the  calling 
user  equipment.  If  overlap  sending  has  been  used,  the 
network  should  send  a  DISCONNECT  message  to  the 
calling  user  equipment.  The  initial  clearing  message 
should  contain  the  appropriate  cause  information,  as 
indicated  below,  and  the  signal  information  'reorder 
tone  on.'  If  tones  and  announcements  apply,  see 
section  5.3.4.1. 


—  Vacant  code:  National-specific  cause  4, 
'vacant  code.' 


Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 

Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 


—  Prefix  0  dialed  in  error:  National-specific 
cause  8,  'prefix  0  dialed  in  error.' 

—  Prefix  1  dialed  in  error:  National-specific 
cause  9  'prefix  1  dialed  in  error.' 

—  Prefix  1  not  dialed:  National-specific 
cause  10,  'prefix  1  not  dialed.'" 

Change  (a)  in  the  first  paragraph  to:  "In  an 
appropriate  call  control  message  when  a  state  change 
is  required  (i.e.,  CONNECT);  or,". 

Delete  from  the  second  paragraph  the  progress 
description  value  "4  'call  has  returned  to  the  ISDN'. 
Call  is  now  end-to-end  and  ISDN." 
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Section  5.1.7 

Call  confirmation  indication 


Section  5.2 

Call  establishment  at  the  destination  interface 
Section  5.2 

Call  establishment  at  the  destination  interface 

Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 


Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 

Section  5.2.2 
Compatibility  checking 

Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 
Section  5.2.3.2 

SETUP  message  delivered  by  broadcast  data  link 


Section  5.2.5.1 

Response  to  en-block  SETUP 
Section  5.2.5.1 

Response  to  en-block  SETUP 
Section  5.2.5.1 

Response  to  en-block  SETUP 
Section  5.2.5.3 

Called  user  clearing  during  incoming  call 
establishment 


Change  the  last  sentence  of  the  first  paragraph  to: 
"When  the  user  receives  the  ALERTING  message,  the 
user  shall  enter  the  Call  Delivered  state." 

Change  "ANSI  standard  T1.602"  to  "NIU  89-210"  in 
the  first  sentence  of  the  first  paragraph. 

Delete  the  third  paragraph  ("The  SETUP  message 
offered  ...  of  the  data  link  layer."). 

Delete  "Display,"  from  the  second  paragraph  "(e.g., 
Display,  Low  layer  compatibility)." 

Add  the  following  to  the  end  of  second  paragraph. 
"In  general,  a  call  terminating  from  a  non-ISDN  line 
or  from  a  Public  Switched  Telephone  Network 
(PSTN)  trunk  should  be  offered  to  the  called  user 
equipment  with  the  3.1.  kHz  audio  bearer  capability." 

Change  "(e.g.,  for  DDI)"  to  "(e.g.,  7  digits)"  in  the 
second  sentence  of  the  third  paragraph. 

Delete  the  third  sentence  from  the  third  paragraph. 


Delete  the  third  paragraph. 


Delete  this  section. 


Combine  the  first  and  second  sentences  of  the  first 
paragraph  to:  "When  the  SETUP  message  is 
delivered  by  a  broadcast  data  link,  the  network  sends 
a  SETUP  message  with  the  Channel  identification 
information  element  indicating  a  specific  channel  with 
no  alternative  acceptable." 

Delete  "(see  Note)"  from  the  first  sentence  of  the  first 
paragraph. 

Delete  the  Note  after  the  first  paragraph. 


Delete  the  third  paragraph  ("When  the  SETUP 
message  was  delivered  via  a  point-to-point  data  link 

..."). 

Delete  the  first  paragraph. 
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Section  5.2.5.3 

Called  user  clearing  during  incoming  call 
establishment 


Change  the  second  sentence  of  the  second  paragraph 
to:  "If  timer  T303  expires  (i.e.,  if  no  valid  message 
such  as  CALL  PROCEEDING,  ALERTING,  or 
CONNECT  has  been  received),  the  network  shall  take 
action  as  follows: 

a.  If  all  clearing  messages  received  from  the 
called  user  equipment  contain  cause  88, 
'incompatible  destination,'  the  call  should  be 
cleared  at  the  calling  ISDN  interface  with 
cause  18,  'no  user  responding  (location: 
public  network  serving  the  remote  user)'  and 
signal  'ring-back/audible  ringing  tone  on.' 

b.  If  one  or  more  call  clearing  messages 
with  cause  17,  'user  busy,'  have  been 
received  from  the  called  user  equipment,  the 
call  should  be  cleared  at  the  calling  ISDN 
interface  with  cause  17, 'user  busy  (location: 
user).'  The  signal  information  should  be 
coded  as  'busy  tone  on'  unless  an  audible 
ringing  tone  was  indicated  because  timer  T 
delay  (if  implemented)  previously  expired 
(see  sec.  5.2.1).  If  audible  ringing  is  being 
provided,  the  signal  information  should  be 
coded  as  'ring-back/audible  ringing  tone  on.' 

c.  If  no  call  clearing  messages  with  cause 
17  have  been  received  from  the  called  user 
equipment  and  at  least  one  call  clearing 
message  with  a  cause  other  than  88  has  been 
received,  the  call  should  be  cleared  at  the 
calling  ISDN  interface  with  cause  21,  'call 
rejected  (location:  user),'  and  signal  'ring- 
back/audible  ringing  tone  on.'". 


Section  5.2.5.3  Delete  the  last  sentence  from  the  second  paragraph: 

Called    user    clearing    during    incoming    call  "When  multiple  RELEASE  COMPLETE  ...  sent  to 

establishment  the  originating  user  (see  5.3)." 


Section  5.2.5.3.1 

DISCONNECT  received  prior  to  expiry  of  T312 


Change  the  second  sentence  in  the  second  paragraph 
from  "If  an  ALERTING  message  has  been  received, 
...  any  other  cause  sent  by  a  called  user."  to  "If  an 
ALERTING  message  has  been  received,  the  cause 
sent  to  the  calling  user  shall  be  21  'call  rejected' 
(location:  user)." 
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Section  5.2.5.3.1 

DISCONNECT  received  prior  to  expiry  of  T312 


Change  the  third  sentence  in  the  second  paragraph 
from  "In  only  CALL  PROCEEDING  ...  sent  by  a 
called  user."  to  "If  only  CALL  PROCEEDING 
messages  have  been  received  from  called  users,  the 
cause  sent  to  the  calling  user  shall  be  as  in  5.2.5.3." 


Section  5.2.5.3.2 

DISCONNECT  received  after  expiry  of  timer  T312 


Change  the  second  sentence  in  the  third  paragraph 
from  "If  an  ALERTING  message  has  been  received, 
...  any  other  cause  sent  by  a  called  user."  to  "If  an 
ALERTING  message  has  been  received,  the  cause 
sent  to  the  calling  user  shall  be  21  'call  rejected' 
(location:  user)." 


Section  5.2.5.3.2 

DISCONNECT  received  after  to  expiry  of  T312 


Change  the  third  sentence  in  the  third  paragraph  from 
"If  only  CALL  PROCEEDING  ...  by  a  called  user"  to 
"If  only  CALL  PROCEEDING  messages  have  been 
received,  the  cause  sent  to  the  calling  user  shall  be  as 
in  5.2.5.3." 


Section  5.2.5.4 
Call  failure 


Delete  all  occurrences  of  "(b) ..."  (paragraphs  1,  3, 4) 
from  this  section. 


Section  5.2.6 
Notification  of 
interface 


interworking  at  the  terminating 


Delete  this  section. 


Section  5.2.7 
Call  accept 


Section  5.2.8 
Active  indication 


Add  to  the  end  of  the  second  paragraph:  "If  the 
CONNECT  message  is  the  first  response  to  the 
SETUP  message,  it  shall  contain  the  channel  ID 
information  element." 

Delete  the  last  paragraph  of  section  5.2.8  ("A  user 
which  has  ...  has  been  completed"). 
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Section  5.3.2 
Exception  conditions 


Add  the  following  before  the  Note  that  appears  at  the 

end  of  this  section. 

—  In  the  case  of  a  SETUP  message  sent  to 
the  user  via  the  broadcast  data  link,  if  a 
called  user  terminal  sends  a  first  response  to 
the  SETUP  message  after  timer  T303  has 
expired  (the  first  expiration  of  T303  is  the 
SETUP  message  should  not  be  retransmitted, 
and  the  second  expiration  of  T303  if  the 
SETUP  message  should  be  retransmitted  — 
note  that  the  SETUP  message  is 
retransmitted  only  when  no  response  is 
received  prior  to  the  first  expiry  of  T303, 
e.g.,  the  SETUP  message  should  not  be 
retransmitted  when  a  call  clearing  message(s) 
is  received  prior  to  the  first  expiry  of  T303), 
but  before  timer  T312  expires,  the  network 
should  clear  the  call  to  that  user  by  sending 
a  RELEASE  message.  This  message 
should  contain  cause  102,  'recovery  on  timer 
expiry'  (location:  public  network  serving  the 
local  user.). 


—  In  the  case  of  call  offering  via  the 
broadcast  data  link,  if  either  timer  T310  or 
T301  expires  at  the  called  user  interface,  the 
network  should  initiate  call  clearing  by 
sending  a  RELEASE  message  to  all  called 
user  equipment  responding  to  the  SETUP 
message  sent  by  the  network.  The 
RELEASE  message(s)  should  contain  cause 
102,  'recovery  on  timer  expiry'  (location: 
public  network  serving  the  local  user). 

—  If  a  call  attempt  is  unsuccessful  and  a 
speech,  3.1  kHz  audio  call  will  not  be 
immediately  cleared  because  inband  tones  or 
announcements  are  being  provided,  the 
network  should  send  the  calling  user  a 
PROGRESS  message  containing  progress 
message  containing  progress  indicator  8, 
'inband  information  or  appropriate  pattern 
now  available.'." 


Section  5.3.3 

Clearing  initiated  by  the  user 


Delete  the  last  Note  in  this  section. 
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Section  5.3.4.1 

Clearing  when  tones  or  announcements  provided 


Add  the  following  at  the  end  of  section  5.3.4.1: 
"To  return  an  inband  tone  for  an  unsuccessful  speech, 
3.1.  kHz  audio  the  network  should  send  a 
PROGRESS  message  and  start  a  tone  timer  (value  to 
be  specified  by  network  provider)  in  anticipation  of 
the  user  initiating  the  clearing  process.  The 
PROGRESS  message  should  contain  the  cause  value 
indicated  in  the  detailed  procedures  of  Section  5.3, 
along  with  progress  indicator  8,  'inband  information 
or  appropriate  pattern  now  available.'  If  the  tone 
timer  expires,  the  network  should  initiate  call  clearing 
by  sending  the  calling  user  a  DISCONNECT  message 
containing  cause  102,  'recovery  on  timer  expiry.' 
The  network  should  then  continue  clearing  the 
connection  to  the  calling  user  equipment  according  to 
the  procedures  for  sending  a  DISCONNECT  message. 
The  procedures  described  above  also  apply  for 
returning  an  inband  announcement  for  an  unsuccessful 
speech,  3.1  kHz  audio  call,  with  the  exception  that  the 
tone  timer  is  not  used.  Inband  announcements  should 
not  be  timed;  however,  it  is  desirable  that  the  network 
Delete  an  inband  announcement  after  one  or  two 
message  cycles,  depending  on  the  number  specified 
by  the  network  provider.  In  removing  the  inband 
announcement,  the  network  should  follow  the  above 
procedures  for  expiration  of  the  tone  timer." 


Section  5.3.4.3 
Completion  of  clearing 


Delete  the  last  Note  at  the  end  of  section  5.3.4.3. 


Section  5.5 
Restart  procedure 


Delete  this  section  including  all  subsections. 


Section  5.8 

Handling  of  error  conditions 


Change  "T1.607"  to  "Q.931"  in  the  first  sentence  of 
the  first  paragraph. 


Section  5.8.1 

Protocol  discrimination  error 


Change  "T1.607"  to  "Q.931"  in  the  first  sentence  in 
the  first  paragraph. 


Section  5.8.3.1 

Invalid  call  reference  format 


Change  the  second  paragraph  to:  "If  the  Call 
reference  information  element  octet  1,  bits  1  through 
4  indicates  a  length  greater  than  the  maximum  length 
supported  by  the  receiving  equipment  (see  4.3),  or  the 
Null  call  reference,  or  the  global  call  reference  is  used 
to  identify  a  call,  then  the  message  shall  be  ignored." 


Section  5.8.3.2 

Call  reference  procedural  errors 


Delete  item  "(f)  When  any  message 
returned." 


shall  be 
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Message  type  or  message  sequence  errors 
Section  5.8.4 

Message  type  or  message  sequence  errors 


Section  5.8.4 

Message  type  or  message  sequence  errors 


Section  5.8.6.1 

Mandatory  information  element  missing 
Section  5.8.6.1 

Mandatory  information  element  missing 


Add  as  a  new  paragraph  "A  NOTIFY  message  may 
also  be  ignored  by  the  recipient."  after  the  first 
paragraph  (i.e.,  after  the  list  of  cause  values). 

Change  the  fourth  sentence  in  the  second  paragraph 
to:  "Whenever  the  network  receives  an  unexpected 
RELEASE  message,  the  network  shall:  disconnect  and 
release  the  B-channel;  clear  the  network  connection 
and  the  call  to  the  remote  user  with  cause  as  specified 
in  5.2.5.3,  or  cause  in  the  RELEASE  message  sent  by 
the  user.  If  no  cause  is  included,  cause  31  'normal, 
unspecified'  or  other  causes  as  specified  in  5.8.6.1; 
return  a  RELEASE  COMPLETE  message  to  the  user; 
release  the  call  reference;  stop  all  timers;  and  enter 
the  Null  state." 

Change  the  second  sentence  of  the  third  paragraph  to: 
"Whenever  the  network  receives  an  unexpected 
RELEASE  COMPLETE  message,  the  network  shall: 
disconnect  and  release  the  B-channel;  clear  the 
network  connection  and  the  call  to  the  remote  user 
with  the  cause  indicated  by  the  user  or,  if  not 
included,  cause  111  'protocol  error,  unspecified'  or 
other  causes  as  specified  in  5.8.6.1;  release  the  call 
reference;  stop  all  timers;  and  enter  the  Null  state." 

Change  the  beginning  of  the  first  sentence  in  the  third 
paragraph  to:  "When  a  DISCONNECT  message  (first 
clearing  message)  is  received  with 

Add  the  following  as  a  new  paragraph  after  the  third 
paragraph:  "As  an  option  the  network  shall  follow 
the  following  procedure.  The  DISCONNECT 
message  sent  to  the  network  should  contain  cause 
information.  If  the  network  receives  an  initial 
clearing  message  without  a  cause  information 
element,  it  should  accept  the  message,  disconnect  the 
associated  channel,  and  initiate  procedures  to  clear  the 
network  connection  and  the  call  to  the  remote  user. 
If  the  call  is  active  or  if  the  originating  user  cleared 
the  call  while  in  the  setup  phase,  the  network  should 
send  cause  16,  'normal  clearing  (location:  user)'  to 
the  remote  user.  It  should  send  cause  21,  'call 
rejected  (location:  user)'  if  the  terminating  user 
cleared  the  call  while  in  the  setup  phase.  The 
network  should  respond  to  the  user  initiating  call 
clearing  by  sending  a  RELEASE  message  containing 
cause  96,  'mandatory  information  element  is  missing 
(location:  public  network  serving  the  local  user; 
diagnostic:  cause  information  element  identifier).'". 
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Section  5.8.6.2 

Mandatory  information  element  content  error 


Change  the  third  paragraph  to:  "When  a 
DISCONNECT  message  is  received  with  invalid 
content  of  the  Cause  information  element,  the  action 
taken  shall  be  the  same  as  if  a  DISCONNECT 
message  with  the  cause  missing  was  received  with  the 
exception  that  the  RELEASE  message  sent  on  the 
local  interface  contains  cause  100  'invalid  information 
element  contents'." 


Section  5.8.7.1 

Unrecognized  information  elements 


Add  the  following  to  the  Note  after  the  first 
paragraph:  "or  not  implemented  by  the  receiver  in  a 
specific  message." 


Section  5.8.8 
Data-link  reset 


Change  "ANSI  T1.607"  to  "NIU  90-301"  in  the  first 
sentence  of  the  first  paragraph. 


Section  5.8.9 
Data-link  failure 


Change  "ANSI  T1.607"  to  "NIU  90-301"  in  the  first 
sentence  of  the  first  paragraph. 


Section  5.8.9 
Data-link  failure 


Change  both  occurrences  of  "ANSI  T1.607"  in  the 
first  paragraph  bullet  b)  to  "NIU  90-301". 


Section  5.8.9 
Data-link  failure 


Change  the  first  Note  after  the  first  paragraph  to:  "If 
the  transfer  mode  of  the  call  is  circuit-mode,  the  NIU 
90-301  entity  may  clear  the  calls." 


Section  5.8.10 

Status  enquiry  procedure 


Delete  the  first  paragraph. 


Section  5.8.11 

Receiving  a  STATUS  message 


Delete  "As  an  option:"  from  the  second  sentence  of 
the  third  paragraph  ("The  determination  ..."). 


Section  5.8.11 

Receiving  a  STATUS  message 


Change  "a)"  in  the  third  paragraph  to:  "If  a  STATUS 
message  indicating  any  call  state  except  the  Null  state 
is  received  in  the  Null  state,  then  the  receiving  entity 
shall  send  a  RELEASE  COMPLETE  message  with  a 
cause  101  'message  not  compatible  with  call  state'  or 
cause  81  'Invalid  Call  reference  value'  and  remain  in 
the  Null  state.  Otherwise,  no  action  shall  be  taken  on 
receipt  of  STATUS  unless  it  is  in  response  to 
STATUS  ENQUIRY." 


Section  5.8.11 

Receiving  a  STATUS  message 


Delete  "b)  If  a  ..."  and  "c)  If  a  STATUS  message, 
indicating  the  Null  ...  into  the  Null  state."  after  the 
third  paragraph. 


Section  5.8.11 

Receiving  a  STATUS  message 


Delete  the  last  three  paragraphs  and  the  last  Note  in 
this  section. 


Section  5.9 

User  notification  procedure 


Delete  this  section. 
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Section  6 

Packet  communication  procedures 


Change  sentence  to  "See  NIU  89-320". 


Change  the  "T302/Default  time  out  value"  cell  from 
"10-15  s"  to  "16-24  s". 


Change  the  "T302/cause  for  start"  cell  from  "SETUP 
ACKNOWLEDGE  sent.  Receipt  of  INFORMATION 
restarts  T302."  to  "SETUP  ACKNOWLEDGE  sent. 
Receipt  of  INFORMATION  not  containing  complete 
address  information  restarts  T302." 

Change  the  "T302/NORMAL  STOP"  cell  to:  "With 
sending  complete  indication,  or  potentially  complete 
address  information  received,  as  an  option,  the 
network  can  determine  that  a  potentially  complete 
code  has  been  received  following  the  receipt  of 
address  information,  and  the  network  could  use 
critical  interdigit  timing  (instead  of  T302)  to 
determine  whether  additional  digits  are  following. 
This  timing  could  be  3-5  seconds.  If  implemented, 
when  this  timer  expires,  a  complete  address  is 
assumed  and  the  procedures  in  Sec.  5.1.5.2  shall  be 
followed.  In  an  INFORMATION  message  is  received 
and  the  critical  interdigit  timing  is  running,  it  shall  be 
stopped." 

Section  9.1  Add  the  following  row  entry  for  Timer  "Tpot_comp" 

Timers  in  the  network  side  after  row  "T302": 

Table  22  —  Timers  in  the  network  side 


TIMER 
NUMBER 

DEFAULT 
TIME 
OUT 
VALUE 

STATE 
OF 

CALL 

CAUSES 

FOR 

START 

NORMAL  STOP 

AT  THE 

FIRST 

EXPIRY 

AT  THE 

SECOND 

EXPIRY 

CROSS 
REFERENCE 

Tpot_comp 

3-5  s 

Overlap 
Sending 

Potentially 

complete 

address 

information 

received 

INFORMATION 
received 

Route 
call 

Timer 
not 

restarted 

* 

"*  optional  —  as  an  option,  the  network  can  determine  that  a  potentially  complete  code  has  been  received  following  the  receipt  of 
address  information,  and  the  network  could  use  critical  interdigit  timing  (instead  of  T302)  to  determine  whether  additional  digits  are 
following.  This  timing  could  be  3-5  seconds.  If  implemented,  when  this  timer  expires,  a  complete  address  is  assumed  and  the 
procedures  in  Sec.  5.1.5.2  shall  be  followed.  In  an  INFORMATION  message  is  received  and  the  critical  interdigit  timing  is  running, 
it  shall  be  stopped." 


Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 
Table  22  —  Timers  in  the  network  side 


Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 
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Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 


Change  the  "T303/DEFAULT  TIME  OUT  VALUE" 
cell  from  "4s"  to  "2.5s". 


Change  the  "T303/NORMAL  STOP"  cell  to  "ALERT, 
CONNECT,  or  CALL  PROCEEDING  received". 


Change  the  "T303/AT  THE  FIRST  EXPIRY"  cell  to 
"Retransmit  SETUP;  re-start  T303." 


Delete  "Note  7"  from  the  "T308/AT  SECOND 
EXPIRY"  cell. 


Change  "10s"  to  "5s"  in  the  "T3 10/DEFAULT  TIME 
OUT  VALUE"  cell. 


Delete  "Note  6"  from  the  "T3 10/DEFAULT  TIME 
OUT  VALUE"  cell. 


Delete  the  following  rows:  "T316",  "T317",  "T321". 


Delete  the  following  Notes:  3,  6,  7  at  the  end  of 
Table  22. 


Change  the  "T301/CROSS  REFERENCE"  cell  to 
"Note  3". 


Change  the  "T303/NORMAL  STOP"  cell  to  "SETUP 
ACKNOWLEDGE,  CALL  PROCEEDING  or 
RELEASE  COMPLETE  received". 

Delete  "(annex  D)"  from  the  "T303/AT  THE  FIRST 
EXPIRY"  cell. 


Change  the  "T303/CROSS  REFERENCE"  cell  to 
"optional". 


Delete  "Note  5"  from  the  "T308/AT  THE  SECOND 
EXPIRY"  cell. 
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Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 


Delete  rows  "T310",  "T316",  "T317",  "T321". 


Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 


Delete  Notes  2  and  5  that  appear  at  the  end  of  table 
7. 


Annex  A 


Delete  this  section.  NOTE:  This  section  has  not 
been  addressed. 


Annex  B,  Section  B.3.1 

Compatibility  checking  with  addressing  information 


Annex  B,  Section  B.3.2 
Network  to  user  compatibility 


Change  the  second  sentence  under  "a)"  to:  "In  the 
case  of  a  mismatch,  the  user  shall  either  ignore  or 
reject  the  call." 

Change  the  last  sentence  in  this  section  to:  "If  a 
mismatch  is  detected,  then  the  user  shall  either  ignore 
or  reject  the  offered  call  using  cause  88  'incompatible 
destination'." 


Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capability  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 
Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capability  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 
Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capability  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 
Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 


Delete  the  "point-to-point  data  link"  columns. 


Change  the  "Incompatible/Broadcast  data  link"  cell 
from  "Reject"  to  "Ignore  or  Reject". 


Delete  "Note  3"  from  the  "Incompatible/broadcast 
data  link"  column. 


Delete  the  reference  to  "Note  1"  from  the  last  column. 
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Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  C,  Section  C.l 
Introduction 

Annex  C,  Section  C.2 
Selection  not  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  D 

Extension  for  symmetric  call  operation 
Annex  E 

Network-specific  facility  selection 
Annex  F 

D-channel  backup  procedure 
A-34 


Change  "Accept  or  Reject"  to  "Accept,  Ignore,  or 
Reject"  in  the  Broadcast  Data  Link  column. 


Delete  Note  1  below  figure  B.3. 


Change  "will  reject  the  call  if  incompatible"  to  "may 
reject  the  call  if  incompatible"  in  Note  2  below  figure 
B.3. 


Delete  Note  3  ("Attempt  low  layer  compatibility 
negotiation  (see  Annex  M).")  below  Figure  B.3. 


Delete  "optional"  from  the  first  paragraph. 
Delete  this  section. 


Change  the  first  sentence  of  the  first  paragraph  to: 
"The  user  identifies  the  selected  transit  network  in  the 
SETUP  message." 

Delete  the  second  and  third  paragraphs. 
Delete  the  first  sentence  of  the  fourth  paragraph. 
Delete  the  last  sentence  in  the  sixth  paragraph. 
Delete  the  seventh,  eighth,  and  ninth  paragraphs. 
Delete  this  section. 


Delete  this  section. 


Delete  this  section. 
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Annex  G,  Section  G.l 
Introduction 


Add  the  following  at  the  end  of  the  first  paragraph: 
"Section  4.5.1 1  identifies  the  causes  supported  in  NIU 
90-301." 


Annex  G 

Cause  Definitions 


Delete  the  following  sections: 

•  Section  G.2.16  Cause  22  "number  changed" 

•  Section  G.3.2  Cause  38  "network  out  of  order" 

•  Section  G.3.7  Cause  45  "preemption" 

•  Section  G.3.8  Cause  46  "precedence  call  blocked" 

•  Section  G.3.9  Cause  47  "resource  unavailable, 
unspecified" 

•  Section  G.4.1  Cause  49  "quality  of  service 
unavailable" 

•  Section  G.4.4  Cause  58  "bearer  capability  no 
presently  available" 

•  Section  G.4.5  Cause  63  "service  or  option  not 
available,  unspecified" 

•  Section  G.5.2  Cause  66  "channel  type  not 
implemented" 

•  Section  G.5.4  Cause  70  "only  restricted  digital 
information  bearer  capability  is  available" 

•  Section  G.5.5  Cause  79  "service  or  option  not 
implemented,  unspecified" 

•  Section  G.6.2  Cause  82  "identified  channel  does 
not  exist" 

•  Section  G.6.4  Cause  91  "invalid  transit  network 
selection" 

•  Section  G.6.5  Cause  95  "invalid  message, 
unspecified" 


Annex  H 

Examples  of  Information  elements  coding 

Annex  H,  Section  H.l 
Introduction 


Change  the  status  of  this  section  from  "informative" 
to  "normative". 

Replace  the  first  and  second  paragraphs  with  the 
following:  "These  are  the  only  recognized  codings  of 
the  following  Information  Elements  for  circuit-mode 
services: 

—  Bearer  capability  information  element 

—  Channel  identification  information  element". 


Annex  H 

Examples  of  information  elements  coding 


Delete  the  following  figures  and  sections: 

•  Figure  "H.3  Coding  for  7  kHz  Audio" 

•  Figure  "H.6  Coding  for  synchronous  1472  kbit/s"; 

•  sections  H.3.2  (Figures  H.9,  H.10,  H.11); 

•  H.3.3  (Figures  H.12  through  H.17); 

•  H.4  (Figures  H.18  through  H.21); 


Annex  H,  Section  H.3.1 

Basic  Interface,  circuit  mode,  B-channel 


Add  Attachment  D  of  this  document. 
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Annex  I 

Use  of  Progress  Indicators 
Annex  I 

Use  of  progress  indicators 
Annex  I 

Use  of  Progress  Indicators 
Annex  I 

Use  of  Progress  Indicators 
Annex  J 

Examples  of  Cause  Values  and  location  for  busy 
condition 

Annex  L 

low  layer  information  coding  principles 
Annex  M 

Low  layer  compatibility  Negotiation 
Annex  N 

Procedures  for  establishment  of  bearer  connection 
prior  to  call  acceptance 

Annex  O 

Optional  procedures  for  bearer  service  change 

Annex  P,  Section  P.l 
Introduction 

Annex  P,  Section  P.l 
Introduction 

Annex  P,  Section  P.l 
Introduction 


Annex  P,  Section  P.l 
Introduction 

Annex  P,  Section  P.2 

Operator  system  access  requested  in  keypad  facility 
information  element 

Annex  P,  Section  P.2 

Operator  system  access  requested  in  keypad  facility 
information  element 


Change  the  status  of  this  Annex  from  "Informative" 
to  "Normative". 

Delete  the  fifth  paragraph  (' 'Progress  Indicator  4  ..."). 


Delete  "or  primary"  from  the  left  side  (between  TE 
and  ISDN)  of  Figure  1.1. 

Delete  "Basic  or"  from  the  right  side  (between  ISDN 
and  NT2)  of  Figure  LI 

Change  "American  National  Standard  T1.607"  to 
"NIU  90-301"  in  the  first  sentence  of  the  first 
paragraph. 

Change  the  first  sentence  of  the  first  paragraph  to: 
"This  annex  is  part  of  NIU  90-301." 

Delete  this  annex. 


Delete  this  annex. 


Delete  this  annex. 


Delete  "optional"  from  the  first  sentence. 

Delete  "or  attendant  system"  from  the  end  of  the  first 
sentence  in  the  first  paragraph. 

Change  the  last  sentence  of  the  first  paragraph  to: 
"These  procedures  apply  to  the  speech  and  3.1  kHz 
audio  bearer  services." 

Delete  "or  attendant  system"  from  the  first  sentence  in 
the  second  paragraph. 

Delete  "or  attendant  system"  from  the  first  sentence  of 
the  first  paragraph. 


Delete  "or  attendant  system"  from  the  last  sentence  of 
the  first  paragraph. 
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Annex  P,  Section  P.3 

Use  of  the  operator  system  access  information 
element 

Annex  P,  Section  P.3 

Use  of  the  operator  system  access  information 
element 

Annex  P,  Section  P.3 

Use  of  the  operator  system  access  information 
element 

Annex  P,  Section  P.3 
Use  of  the  operator 
element 

Annex  Q 

Responding  address  requirements  of  the  OSI  network 
layer  service 

Annex  R 

Application  of  the  Signal  Information  Element  to 
Tones  and  Alerting  Patterns 

Annex  R 

Application  of  the  Signal  Information  Element  to 
Tones  and  Alerting  Patterns 
Table  21  —  Tones 

Annex  S 

Comparison  of  CCITT  Recommendation  Q.931  to 
ANSI  T1.607 


Delete  "or  attendant  system"  from  the  first  sentence  of 
the  first  paragraph. 

Delete  "c)  Private/principal ...  SETUP  message."  from 
the  second  paragraph. 

Delete  "or  attendant  system"  from  the  third  paragraph. 


Delete  this  annex. 


Change  the  status  of  this  Annex  from  "informative"  to 
"normative". 


Delete  the  following  rows:  2,  6,  8. 


Delete  this  annex. 


Delete  the  sixth  paragraph. 

system  access  information 
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Attachment  A 

(of  Appendix  A) 

1.  General 

1.1  Scope  and  Purpose 

This  Implementation  Agreement  specifies  a  minimal  subset  of  procedures  and  codepoints  from  the  American  National 
Standards  Tl  .607- 1990  (Ref.  [17])  for  the  establishment,  maintenance,  and  clearing  of  ISDN  connections  at  the  user- 
to-network  interface.  This  signalling  standard  is  used  to  support  the  circuit-switched  bearer  services  specified  in 
ANSI  standards  T1.603*. 

Terminals  are  not  required  to  support  all  services.  Switches  will  support  all  of  the  mandatory  protocols  and 
codepoints  in  this  implementation  agreement.  This  does  not  preclude  the  support  of  additional  services  and 
procedures.  However,  equipment  must  be  able  to  interoperate  with  equipment  supporting  only  this  minimal  subset. 

1.1.1  Definitions 

The  ANS  Tl.607-1990  (Ref.  [17])  assumes  that  procedures  apply  generically  to  ISDN  access  interfaces,  i.e.,  the 
document  does  not  distinguish  between  basic  and  primary  rates  access  interfaces.  In  addition,  there  are  no  references 
to  specific  applications  in  that  document.  The  concept  of  equipment  classes  is  introduced  in  this  document  to  permit 
certain  procedures  to  be  associated  with  a  particular  application  or  class  of  equipment,  e.g.,  station  equipment  versus 
PBX.  Specifically,  two  classes  of  equipment  are  defined  on  the  basis  of  two  fundamental  attributes. 

The  first  attribute  relates  to  the  possibility  of  an  exchange  of  signals  occurring  beyond  the  public  network's  point 
of  contact  with  the  interface  (i.e.,  between  the  equipment  directly  connected  to  the  public  network  and  ISDN 
terminals  or  telephones  connected  to  that  equipment).  For  example,  some  user  equipment  may  support  subtending 
Basic  Access  digital  subscriber  loops  and/or  analog  telephone  loops.  For  Class  I  equipment,  the  network  makes  no 
provision  for  such  an  arrangement  and  assumes  the  Class  I  equipment  constitutes  the  endpoint  of  the  communication. 
Conversely,  in  the  case  of  Class  II  equipment,  the  procedures  at  the  network  take  into  account  that  communication 
between  Class  II  equipment  (with  which  it  communicates  directly)  and  other  equipment  (with  which  the  network  does 
not  have  direct  contact)  may  occur.  As  an  example,  Class  II  equipment  may  support  digital  and/or  analog  subscriber 
loops.  Use  of  Class  II  equipment  also  involves  the  possibility  of  having  interworking  occur  beyond  the  equipment 
with  which  the  network  has  direct  contact.  Therefore,  it  is  reasonable  for  Class  II  equipment  to  provide  the  network 
with  an  interworking  notification,  for  both  outgoing  and  incoming  calls,  when  either  the  calling  or  called  party 
respectively,  is  a  non-ISDN  user.  Class  II  equipment  may  also  send  an  interworking  notification  if  a  private  network 
exists  beyond  the  Class  II  equipment  and  interworking  to  a  non-ISDN  facility  within  that  network  takes  place.  When 
an  interface  is  associated  with  Class  I  equipment,  it  is  assumed  the  multiple  pieces  of  equipment  may  exist  and 
communicate  with  the  network  over  the  D-channel.  However,  in  this  case,  all  equipment  is  assumed  to  be  ISDN- 
capable  and  is  considered  as  the  endpoint  of  the  communication.  Therefore,  interworking  notification  should  not  be 
accepted  from  Class  I  equipment. 

The  second  attribute  relates  to  the  manner  in  which  a  SETUP  message  should  be  presented  to  the  user  equipment. 
When  Class  I  equipment  is  applied  on  a  particular  interfaces,  the  network  should  broadcast  the  SETUP  message 
associated  with  each  call  that  terminates  on  that  interface,  since  interaction  between  the  network  and  multiple  pieces 
of  user  equipment  should  be  supported.  On  the  other  hand,  the  network  should  not  broadcast  SETUP  messages 


Subject  to  further  discussion. 
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associated  with  terminating  calls  to  an  interface  on  which  Class  II  equipment  is  being  used.  Here,  a  single  piece 
of  user  equipment  is  assumed  to  be  involved  in  all  communication  with  the  network. 

To  the  extent  possible,  it  is  desirable  to  have  one  set  of  requirements  for  ISDN  call  control  apply  to  all  ISDN  user 
configurations.  However,  in  cases  for  which  integrated  procedures  are  not  appropriate,  the  call  control  procedures 
associated  with  Equipment  Class  I  will  differ  from  those  associated  with  Equipment  Class  II.  Unless  otherwise 
noted,  the  assumption  should  be  that  a  particular  procedure/capability  should  be  provided  for  both  classes  of 
equipment  on  both  basic  and  primary  rate  access.  However,  use  of  the  equipment  class  terminology  permits 
clarification  of  the  circumstances  under  which  a  certain  capability  should  be  available  (i.e.,  when  a  particular 
equipment  class  is  in  use).  It  also  permits  a  mechanism  for  indicating  that  a  particular  capability  applies  only  to  a 
subset  of  four  possible  configurations  which  are  labeled  as  follows. 


Class  I  Class  n 


IB 

IIB 

IP 

IIP 

In  other  words,  a  capability  that  applies  to  Class  I  equipment  may  be  provided  on  basic  access  interfaces  (IB)  and/or 
primary  rate  access  interfaces  (TP).  Similarly,  a  capability  that  applies  to  Class  II  equipment  may  be  provided  on 
basic  access  interfaces  (IIB)  and/or  primary  rate  access  interfaces  (HP). 


The  notation  shown  in  the  table  above  is  used  within  this  implementation  agreement  to  indicate  when  protocol  or 
procedures  are  only  expected  to  be  supported  for  a  particular  equipment  class  and/or  are  limited  to  a  particular  type 
of  interface,  i.e.,  basic  or  primary  rate  interface. 
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Attachment  B 

(of  Appendix  A) 

The  various  parts  of  the  called  party  number  information  element  should  be  coded  as  follows: 

—  Type  of  number  and  numbering  plan  (octet  3) 
Bits 

7  6  5  4  3  2  1   Meaning  

0  0  0  0  0  0  0  Unknown 

0  0  1  0  0  0  1    International  number  in  ISDN  numbering  plan  (Rec.  E.164) 

0  1  0  0  0  0  1    National  number  in  ISDN  numbering  plan  (Rec.  E.164) 

1  0  0  0  0  0  1  Local  (directory)  number  in  ISDN  numbering  plan  (Rec.  E.164) 
1  10  10  0  1    Abbreviated  Number  in  Private  Numbering  plan 

All  other  values  are  reserved 


—  Digits  (octet  4,  etc.) 

Bits 

7  6  5  4  3  2  1  Meaning 

0  110000  0 

0  110001  1 

0  110  0  10  2 

0  110  0  11  3 

0  110  10  0  4 

0  110  10  1  5 

0  110  110  6 

0  110  111  7 

0  111000  8 

0  111001  9 

All  other  values  are  reserved 

Digits  should  be  represented  by  IA5  characters  whose  encoding  is  shown  above. 

In  the  network  to  user  direction  (n  ->  u),  this  IE  will  be  always  signaled  in  the  SETUP  message,  and  public  network 
interfaces  will  use  only  one  codepoint:  local  number  in  ISDN.  For  private  networks,  this  IE  can  contain  the 
following  codepoints:  abbreviated  type  of  number,  and  private  numbering  plan,  and  extra  digits  such  A,  B,  C,  and 
D  (as  per  IA5). 
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Attachment  C 

(of  Appendix  A) 


The  various  parts  of  the  calling  party  number  information  element  should  be  coded  as  described  below.  The 
numbering  plans  are  as  described  in  CCITT  Recommendations  E.164  or  X.121. 

—  Type  of  number  and  numbering  plan  (octet  3)  follows: 

Bits 

7  6  5  4  3  2  1  Meaning  

0  0  0  0  0  0  0  Unknown 

0  0  1  0  0  0  1  International  number  in  ISDN  numbering  plan  (Rec.  E.164) 

0  0  1  0  0  1  1  International  number  in  data  numbering  plan  (Rec.  X.121) 

0  1  0  0  0  0  1  National  number  in  ISDN  numbering  plan  (Rec.  E.164) 

1  0  0  0  0  0  1  Local  (directory)  number  in  ISDN  numbering  plan  (Rec.  E.164) 
1  10  10  0  1  Abbreviated  Number  in  Private  Numbering  plan 

All  other  values  are  reserved 

—  Origin  of  number  and  presentation  status  (octet  3a)  follows: 

Bits 

7  6  5  4  3  2  1  Meaning 


0  0  0  0  0  0  0    Presentation  allowed  of  user-provided  number, 
number  not  screened 

0  0  0  0  0  0  1    Presentation  allowed  of  user-provided  number, 
number  passed  network  screening 

0  0  0  0  0  1  0    Presentation  allowed  of  user-provided  number, 
number  failed  network  screening 

0  0  0  0  0  1  1    Presentation  allowed  of  network-provided  number 

0  1  0  0  0  0  0    Presentation  prohibited  of  user-provided  number, 

number  not  screened 
0  1  0  0  0  0  1    Presentation  prohibited  of  user-provided  number, 

number  passed  network  screening 

0  1  0  0  0  1  0    Presentation  prohibited  of  user-provided  number, 
number  failed  network  screening 

0  1  0  0  0  1  1    Presentation  prohibited  of  network-provided  number 

1  0  0  0  0  1  1    Number  not  available 

All  other  values  are  reserved 

Notes 

1  When  octet  3a  is  omitted,  the  default  value  of  Number  Presentation  parameter  for  the  signaled  DN  value 
should  be  used,  if  it  is  available.  If  a  value  for  this  parameter  is  unavailable  (i.e.,  the  signaled  DN  value 
either  fails  screening  or  is  not  screened  by  the  SPCS),  the  presentation  parameter  value  of  the  default  DN 
should  be  used. 

2  Octet  3a,  bits  7  and  6  are  for  the  Presentation  Indicator;  bits  2  and  1  are  for  the  Screening  Indicator. 
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—  Digits  (octet  4,  etc.) 


Digits  should  be  represented  by  IA5  characters  whose  encoding  is  shown  below: 

Bits 

7  6  5  4  3  2  1  Meaning 


0 

1 

1 

0  000 

0 

0 

1 

1 

000  1 

1 

o 

1 

1 

0  0  10 

2 

0 

1 

1 

0  0  11 

3 

0 

1 

1 

0  100 

4 

0 

1 

1 

0  10  1 

5 

0 

1 

1 

0  110 

6 

0 

1 

1 

0  111 

7 

0 

1 

I 

1000 

8 

0 

1 

1 

100  1 

9 

All  other  values  are  reserved 
Codings  At  Originating  Party  Interface 

The  calling  party  number  information  element  should  only  be  accepted  when  in  the  SETUP  message.  When 
the  type  of  number  and  numbering  plan  indicator  indicates  "local  number  in  the  ISDN  (E.164)  numbering 
plan",  the  calling  party  number  information  element  should  contain  a  7-digit  local  number.  When  the  type 
of  number  and  numbering  plan  indicator  indicates  "national  number  in  the  ISDN  (E.164)  numbering  plan" 
the  calling  party  number  information  element  should  contain  a  10-digit  national  number. 

In  the  network  to  user  direction  (n  ->  u),  the  coding  and  delivery  of  this  IE  depends  on  the  definition  of 
the  Calling  Line  ID  service.  For  private  networks,  this  IE  can  contain  the  following  codepoints:  abbreviated 
type  of  number,  and  private  numbering  plan,  and  extra  digits  such  as  A,  B,  C,  and  D  (as  per  IA5). 
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Attachment  D 

(of  Appendix  A) 


•  add  the  following  figures  to  section  H.3.1 

8        7        6        5        4  3  2         1  octet 


Channel  identification 

0 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

1 

0 

0  1 

int 

int 

Pref/ 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-1.  Channel  Bl  exclusive. 


8         7         6       5       4  3  2         1  octet 


Channel  identification 

0 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

0 

0 

1  0 

int 

int 

Pref/ 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-2.  Channel  B2  preferred. 
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8 

7 

6 

5 

4 

3 

2  1 

Channel  identification 

0 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

1 

0 

1  0 

int 

int 

Pref/ 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-3.  Channel  B2  exclusive. 


8       7        6       5       4  3  2         1  octet 


Channel  identification 

0 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

0 

0 

1  1 

int 

int 

Pref/ 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-4.  Any  B-channel. 
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8        7         6        5        4  3  2  1 


octet 


Channel  identification 

o 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

0 

0 

0  0 

int 

int 

Piety 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-5.  No  B-channel  Indicated. 


NIU-Forum  Agreements  On  ISDN 


A-45 


APPENDIX  B. 


NTU  90-302 
Implementation  Agreement 
of  the  North  American  ISDN  Users'  Forum 

Layer  3  Signalling  Specification  for  the 
Minimal  Set  of  Circuit-Switched  Bearer  Services  for 
the  ISDN  Class  II  Primary  Rate  Interfaces. 

Baseline  Text 

American  National  Standard  T  1.607- 1990: 
Integrated  Services  Digital  Network  (ISDN)  — 
Layer  3  Signalling  Specification  for 
Circuit-Switched  Bearer  Service  for 
Digital  Subscriber  Signalling  System  Number  1  (DSS1). 

Base  Standards 
CCITT  Recommendation  Q.931  (1988): 
ISDN  User-Network  Interface  Layer  3 
Specification  For  Basic  Call  Control. 

ANSI  Tl. 607- 1990 
ANSI  Tl.603-1990': 
Integrated  Services  Digital  Network  (ISDN)  — 
Minimal  Set  of  Bearer  Services  for 
the  Primary  Rate  Interface. 

B.l  Abstract 

This  Implementation  Agreement  specifies  procedures  for  establishing,  maintaining,  and  clearing  connections  at  the 
Integrated  Services  Digital  Network  (ISDN)  user-network  interfaces  identified  as  Class  II  PRI,  and  are  mandatory 
for  the  support  of  the  minimal  set  of  circuit-switched  bearer  services  specified  by  ANSI  Tl.603-1990*  Integrated 
Services  Digital  Network  (ISDN)  —  Minimal  Set  of  Bearer  Services  for  the  Primary  Rate  Interface,  (Ref.  [14]). 
Procedures  for  circuit-mode  digital,  circuit-mode  speech  and  circuit-mode  voiceband  data  bearer  services  are  as 
specified  in  the  baseline  text  ANS  Tl.607-1990,  Integrated  Services  Digital  Network  (ISDN)  —  Digital  Subscriber 
Signalling  System  Number  1  (DSS1)  —  Layer  3  Signalling  Specification  for  Circuit-Switched  Bearer  Service,  (Ref. 
[17]),  as  further  resolved  by  this  agreement.  The  packet-mode  data  service  is  included  in  this  document  as  a  bearer 
service.  Procedures  for  the  packet-mode  bearer  service  will  be  detailed  in  another  document. 


Subject  to  further  discussion 
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B.2  Introduction 


The  original  implementation  agreement  (NTU  90-302)  was  reached  by  marking  up  the  text  of  ANS  T  1.607- 1990, 
(Ref.  [17])  to  reflect  the  clarifications  of  text  and  selection  of  options.  This  appendix  translates  the  implementation 
agreement  markup  into  a  listing  of  these  clarifications  and  selections,  (i.e.,  this  appendix  lists  the  differences  [the 
"delta"]  between  the  implementation  agreement  marked  up  ANS  Tl. 607- 1990,  and  the  original  text  of  ANS  T1.607- 
1990). 

B.3  NIU  90-302  Delta  List" 

The  IA  has  adopted  the  ANS  Tl.607-1990***  (Ref.  [17])  standard  with  the  following  clarifications  of  the  text,  and 
selection  of  options: 


ANS  Tl.607-1990 
SECTION/TABLE  NUMBER/NAME 


IMPLEMENTATION  AGREEMENTS  - 
CLARIFICATION  OF  TEXT  AND 
SELECTION  OF  OPTIONS 


Section  1.1 
Scope  and  Purpose 


Replace  this  section  with  Attachment  A  of  this 
document. 


Section  2.1.1.3 
Overlap  Sending  (U2) 


Delete  this  section. 


Section  2.1.2.3 
Overlap  Sending  (N2) 


Delete  this  section. 


Section  2.1.2.14 
Call  Abort  (N22) 


Delete  this  section. 


Section  3.1 

Table  1  —  Messages  for  circuit-mode  connection 
control 


Delete  the  following  message  and  reference: 
"INFORMATION  3.1.6". 


Section  3.1 

Table  1  —  Messages  for  circuit-mode  connection 
control 


Delete  the  following  message  and  reference:  "SETUP 
ACKNOWLEDGE  3.1.12". 


Section  3.1 

Table  1  —  Messages  for  circuit-mode  connection 
control 


Change  "NOTIFY    3.1.7"  to  "NOTIFY*". 


Note  that  this  Delta  List  was  developed  in  "good  faith"  by  NIST  as  a  simple  equivalent  representation  of 
the  actual  agreements.  It  has  been  reviewed  and  approved  by  the  editors  of  the  Signalling  Working  Group 
as  per  recommendation  of  the  Executive  Steering  Committee. 

These  documents  can  be  purchased  from:  American  National  Standards  Institute,  1 1  West  42nd  Street,  New 
York,  NY  10036. 
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Section  3.1 

Messages  for  circuit-mode  connection  control 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  -  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 


Add  the  following  footnote  below  Table  1  "*  See 
section  5.8.4  for  treatment  of  this  message." 

Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal". 

Delete  Notes  4,  5,  6. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Channel  identification/Type"  cell  from 
"0(Note  1)"  to  "M". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 

Delete  rows 

•  "Progress  indicator"; 

•  "Display". 

Delete  Notes  1,  2,  3,  4. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 
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Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal"; 

•  "Connected  number"; 

•  "Connected  subaddress"; 

•  "Low  layer  compatibility". 

Change  Note  3  to:  "Included  in  the  event  of 
interworking." 


Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 
Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 


Delete  Notes  4,  5,  6,  7,  8,  9. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal". 


Delete  Notes  1,  2,  3. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Length"  from  "4-32"  to  "4-10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal"' 

•  "Connected  Number"; 

•  "Connected  subaddress". 


Section  3.1.5  Delete  Notes  1,  2,  3,  4,  and  5. 

DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.6  Delete  this  section. 

INFORMATION 
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Section  3.1.7 
NOTIFY 


Delete  this  section. 


Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 


Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Length"  cell  from  "2-32"  to  "2, 4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal". 

Delete  Notes  2,  3,  4. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Length"  cell  from  "2-32"  to  "2, 4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal"; 

•  "Connected  number"; 

•  "Connected  subaddress". 

Delete  Notes  3,  4,  5,  6,  7. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Section  3.1.10  Change  the  "Cause/Length"  cell  from  "2-32"  to  "2, 4- 

RELEASE  COMPLETE  10". 
Table  1 1  —  RELEASE  COMPLETE  message  content 
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Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal"; 

•  "Connected  number"; 

•  "Connected  subaddress". 

Delete  Notes  3,  4,  5,  6,  7. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Delete  the  following  rows: 

•  "Repeat  indicator"; 

•  "Display"; 

•  "Keypad  facility"; 

•  "Signal". 

Change  the  "Bearer  capability/Type"  cell  from 
"M(Note  2)"  to  "M". 


Change  the  "Bearer  capability/Length"  cell  from  "4- 
13"  to  "4-8". 


Change  the  "Channel  identification/Type"  cell  from 
"0(Note  3)"  to  "M". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "5-6". 


Change  the  "Network  specific  facilities/Length"  cell 
from  "2-*"  to  "2-32". 


Change  the  "Calling  party  number/Length"  cell  from 
"2-*"  to  "2-19". 


Change  the  "Called  party  address/Length"  cell  from 
"2-*"  to  "2-18". 


B-6 


NIU-Forum  Agreements  on  ISDN 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Section  3.1.12 

SETUP  ACKNOWLEDGE 

Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Change  the  "Transit  network  selection/Length"  cell 
from  "2-*"  to  "2-7". 


Change  the  "High  layer  capability/Length"  cell  from 
"2-4"  to  "2-5". 


Delete  Notes  1,  2,  3,  6,  7,  8,  9. 


Change  Note  4  to:  "Included  in  the  event  of 
interworking." 

Change  the  first  sentence  of  Note  12  to:  "The  called 
party  number  information  element  is  included  by  the 
user 

Change  the  first  sentence  of  Note  20  to:  "This 
information  applies  to  speech  and  3.1  kHz  audio 
bearer  services." 

Add  the  following  to  the  end  of  Note  13:  "The 
network  should  transport  this  EE  transparently.  This 
IE  is  optional  on  the  user  side." 

Add  the  following  to  the  end  of  Note  15:  "The 

network  should  transport  this  EE  transparendy.  This 
IE  is  optional  on  the  user  side.  The  total  length  is  2 
to  16  octets." 

Add  the  following  to  the  end  of  Note  16:  "The 

network  should  transport  this  IE  transparently.  This 
IE  is  optional  on  the  user  side." 

Add  the  following  to  the  end  of  Note  17:  "The 
network  will  treat  this  IE  on  sending  and  receiving  as 
described  in  the  User-User  supplementary  service 
Implementation  Agreement." 

Delete  this  section. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 
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Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 

Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 

Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 

Section  3.1.14 
STATUS  ENQUIRY 


Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.2.1 
RESTART 

Table  17  —  RESTART  message  content 

Section  3.2.1 
RESTART 

Table  17  —  RESTART  message  content 

Section  3.2.1 
RESTART 

Table  17  —  RESTART  message  content 

Section  3.2.1 
RESTART 

Table  17  —  RESTART  message  content 
Section  3.2.2 

RESTART  ACKNOWLEDGE 

Table  18  —  RESTART  ACKNOWLEDGE  message 

content 


Change  the  "Cause/Length"  cell  from  "4-32"  to  "4- 
10". 


Delete  row  "Display". 


Delete  Notes  1,  2. 


Change  the  first  sentence  to:  "This  message  is  sent 
by  the  user  or  the  network  during  the  active  state  to 
solicit  a  STATUS  message  from  the  peer  layer  3 
entity." 

Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Delete  row  "Display". 


Delete  Notes  1,  2. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 


Delete  row  "Display". 


Delete  Notes  3,  4. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


B-8 


NIU-Forum  Agreements  on  ISDN 


Section  3.2.2 

RESTART  ACKNOWLEDGE 

Table  18  —  RESTART  ACKNOWLEDGE  message 

content 

Section  3.2.2 

RESTART  ACKNOWLEDGE 

Table  18  —  RESTART  ACKNOWLEDGE  message 

content 

Section  3.2.2 

RESTART  ACKNOWLEDGE 

Table  18  —  RESTART  ACKNOWLEDGE  message 

content 

Section  4.2 

Protocol  discriminator 


Section  4.2 

Protocol  discriminator 

Figure  2  —  Protocol  Discriminator 

Section  4.2 

Protocol  discriminator 

Table  19  —  Protocol  Discriminator 

Section  4.3 
Call  reference 


Section  4.3 
Call  reference 

Section  4.3 
Call  reference 

Figure  4  —  Dummy  call  reference 

Section  4.3 
Call  reference 


Section  4.3 
Call  reference 

Section  4.4 
Message  type 

Table  20  —  Message  types 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 


Delete  row  "Display". 


Delete  Notes  3,  4. 


Add  the  following  sentence  after  the  first  sentence  in 
the  second  paragraph:  "The  only  value  supported  for 
call  control  messages  is  described  below  in  Figure  2." 

Change  "ANSI  T1.607"  to  "Q.931". 


Change  "ANSI  T1.607"  to  "Q.931"  in  row  "0000 
1000". 


Change  the  third  paragraph  ("At  a  minimum  ...")  to: 
"At  a  minimum,  all  networks  and  users  must  be  able 
to  support  a  call  reference  value  of  one  and  two  octets 
for  a  primary  rate  interface." 

Delete  the  first  sentence  of  the  fourth  paragraph  "As 
a  network  ...  also  be  supported." 

Change  "Figure  4.  Dummy  call  reference"  to  "Figure 
4.  Dummy  call  reference  *". 

Add  the  following  footnote  after  Figure  4:  "*The 
dummy  call  reference  is  not  supported  for  primary 
rate  Class  II  circuit-switched  calls." 

Delete  Note  1  ("The  call  reference  ...  ")  at  the  end  of 
the  section. 

Delete  the  following  rows: 

•  "SETUP  ACKNOWLEDGE"; 

•  "INFORMATION". 
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Section  4.4 
Message  type 

Table  20  —  Message  types 

Section  4.5.1 
Coding  rules 

Section  4.5.1 
Coding  rules 

Figure  7  —  Formats  of  information  elements 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 


Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 


Add  the  following  to  the  end  of  row  "NOTIFY": 
"(see  sec.  5.8.4  for  treatment  of  this  message  type)." 


Delete  the  second,  third,  and  fourth  sentences  from 
the  fourth  paragraph. 

Delete  figure  (b)  Single  octet  information  element 
format  (type  2). 


Delete  the  following  rows: 

•  "Repeat  indicator"; 

•  "Notification  indicator"; 

•  "Display"; 

•  "Keypad  facility"; 

•  "Signal"; 

•  "Connected  number"; 

•  "Connected  subaddress"; 

•  "Escape  for  extension". 

Delete  reference  to  "(Note  6)"  from  "Bearer 
capability"  row. 


Change  the  "Bearer  capability/Max  length"  cell  from 
"13"  to  "8". 


Change  the  "Cause/Max  length"  cell  from  "32"  to 
"10". 


Change  the  "Cause/Max  no  of  occurrences"  cell  from 
"3"  to  "2". 


Change  the  "Channel  identification/Max  length"  cell 
from  "(Note  4)"  to  "6". 


Change  the  "Network-specific  facilities/Max  length" 
cell  from  "(Note  4)"  to  "32". 


Change  the  "Network-specific  facilities/Max  no.  of 
occurrences"  cell  from  "4"  to  "2". 
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Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 


Change  the  "Calling  party  number/Max  length"  cell 
from  "(Note  4)"  to  "19". 


Change  the  "Called  party  number/Max  length"  cell 
from  "(Note  4)"  to  "18". 


Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 


Delete  reference  to  "(Note  2)"  from  "Transit  network 
selection"  row. 


Change  the  "Transit  network  selection/Max  length" 
cell  from  "(Note  4)"  to  "7". 


Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 


Delete  "4"  from  the  "Transit  network  selection/Max 
no.  of  occurrences"  cell. 


Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Figure  8  —  Information  element  format  using  escape 
for  extension 


Change  the  "High  layer  compatibility/Max  length"  cell 
from  "4"  to  "5". 


Delete  Notes  3,  4,  6. 


Delete  this  figure. 


Section  4.5.2 
Extensions  of  codesets 


Change  "T1.608"  to  "NTU  89-320"  in  the  first  bullet 
in  the  fourth  paragraph. 
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Section  4.5.2 
Extensions  of  codesets 


Replace  the  tenth  paragraph  ("Codeset  6  ...")  with  the 
following: 


Section  4.5.3 

Locking  shift  procedure 

New  codeset  identification  table 

Section  4.5.4 

Non-locking  shift  procedures 
Section  4.5.4 

Non-locking  shift  procedures 
Temporary  codeset  identification  table 

Section  4.5.4 

Non-locking  shift  procedures 
Temporary  codeset  identification  table 

Section  4.5.5 
Bearer  Capability 


Section  4.5.5 
Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 


"Codeset  6  is  reserved  for  information  elements 
specific  to  the  local  network  (either  public  or  private). 
These  information  elements  can  appear  in  a  call 
establishment  (i.e.,  SETUP,  ALERTING,  or 
CONNECT)  or  first  clearing  message.  As  such,  they 
do  not  have  significance  across  a  national  or 
international  boundary.  For  these  two  cases,  codeset 
6  information  elements  shall  be  handled  according  to 
the  procedures  for  unrecognized  information  elements 
(see  sec.  5.8.7.1)  beyond  the  local  network  boundary. 
Inside  a  private  local  network  recognized  codeset  6 
information  elements  shall  be  consumed,  manipulated, 
or  passed  transparently  according  to  the  rule  for  that 
information  element.  Across  the  boundary  between 
local  networks  (e.g.,  a  public  and  a  private  network), 
recognized  codeset  6  information  elements  shall  be 
consumed  and  manipulated  according  to  the  rule  for 
that  information  element.  Inside  a  private  local 
network,  unrecognized  codeset  6  information  elements 
may  be  passed  transparently.  Across  the  boundary 
between  a  private  local  network  and  a  public  local 
network,  unrecognized  codeset  6  information  elements 
shall  be  either  treated  as  per  section  5.8.7.1  or  passed 
transparently  if  a  bilateral  agreement  exists." 

Change  "T1.608"  to  "NIU  89-320"  for  codeset  5. 


Delete  "a)  process  the  nonblocking  ...  as  described 
below"  from  the  second  paragraph. 

Change  "T1.607"  to  "NIU  90-302"  for  codeset  0. 


Change  "T1.608"  to  "NIU  89-320"  for  codeset  5. 


Change  "13  octets"  to  "8  octets"  in  the  second 
sentence  ("The  maximum  length  ...")  of  the  second 
paragraph. 

Change  octet  4,  bit  8  from  "0/1"  to  "1". 
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Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 


Section  4.5.5 
Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 


Section  4.5.5 
Bearer  Capability 

Information  transfer  capability  (octet  3)  coding 

Section  4.5.5 
Bearer  Capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  Capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  Capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  Capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  Capability 


Section  4.5.5 
Bearer  Capability 

User  information  layer  1  protocol  (octet  5)  coding 


Delete  the  following  octets: 

•  4a; 

•  4b; 

•  5b  (Note  2); 

•  5b  (Note  3); 

•  5c; 

•  5<L 

Change  octet  5a,  bit  8  from  "0/1"  to  "1". 


Delete  Notes  1,  2,  3. 


Add  the  following  after  Note  4:  "5  Octets  6  and  7 
are  included  for  information  only.  The  coding  and 
application  of  these  octets  are  included  in  another 
document." 

Delete  row  "10001  7  kHz  audio". 


Change  the  title  to  "Information  transfer  rate  (octet 
4)". 


Delete  the  following  rows:  "10011  384  kbit/s", 
"10100  1472  kbit/s  (Note  2)",  "10101  1526  kbit/s". 

Change  Note  1  to:  "The  bearer  capability  is 
bidirectional  symmetric  at  the  information  transfer 
rate  specified  in  octet  4." 

Delete  Note  2. 


Delete  all  codings  and  text  referring  to  octet  4a 
(structure,  configuration,  establishment)  and  octet  4b 
(symmetry). 

Delete  "and  optionally  octets  5b,  5c,  and  5d  as 
defined  below."  from  row  "00001". 
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Section  4.5.5 
Bearer  Capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  Capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  Capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  Capability 

Synchronous/asynchronous  (octet  5a)  coding 

Section  4.5.5 
Bearer  Capability 

Synchronous/asynchronous  (octet  5a)  coding 

Section  4.5.5 
Bearer  Capability 
Negotiation  (octet  5a)  coding 

Section  4.5.5 

Bearer  Capability 

User  rate  (octet  5a)  coding 

Section  4.5.5 
Bearer  Capability 


Section  4.5.5 
Bearer  Capability 


Section  4.5.6 
Call  state 

Call  state  value  (octet  3)  coding 

Section  4.5.6 
Call  state 

Call  state  value  (octet  3)  coding 


Delete  "and  G.725  7  kHz  audio"  from  row  "00101". 


Delete  rows  "00111"  and  "01000". 


Delete  Note  2. 


Delete  row  "1  asynchronous". 


Delete  the  second  and  third  sentences  from  the  Note. 


Delete  row  "1  In-band  negotiation  possible". 


Delete  all  rows  except  row  "01111  56  kbi(/s  CCITT 
Recommendation  V.6". 


Delete  all  text  relating  to  octet  5b  (i.e.,  sections 
labeled  "Octet  5b  for  CCITT  Recommendation  V.100 
or  X.30  rate  adaption"  and  "Octet  5b  for  CCITT 
Recommendation  V.120  rate  adaption".) 

Delete  all  codings  and  text  referring  to  octets  5c 
(number  of  data  bits  excluding  parity  bit,  parity 
information)  and  5d  (duplex  mode,  modem  type). 

Delete  row  "000010  U2  —  overlap  sending". 


Add  the  following  column  to  the  right  of  the  coding: 
Symmetric  States* 

50  —  Null 

51  —  Call  Initiated 

53  —  Outgoing  Call  Proceeding 

54  —  Call  Delivered 

56  —  Call  Present 

57  —  Call  Received 

58  —  Connect  Request 

59  —  Incoming  Call  Proceeding 


B-14 


NIU-Forum  Agreements  on  ISDN 


Section  4.5.6 
Call  state 

Call  state  value  (octet  3)  coding 

Section  4.5.6 
Call  state 

Call  state  value  (octet  3)  coding 

Section  4.5.7 
Called  party  number 

Section  4.5.7 

Called  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.7 

Called  party  number 

Type  of  number  (octet  3)  coding 


Section  4.5.7 

Called  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.7 
Called  party  number 

Numbering  Plan  Identification  (octet  3)  coding 


Section  4.5.7 
Called  party  number 

Numbering  plan  identification  (octet  3)  coding 


Section  4.5.7 
Called  party  number 


Section  4.5.9 
Calling  party  number 


510  —  Active 

511  —  Disconnect  Request 

512  —  Disconnect  Indication 
S19  —  Release  Request 

Add  the  following  after  the  coding:  "*Note  —  For 
Symmetric  states  see  Annex  D." 


Delete  "N22  —  Call  abort"  from  the  "010110/ 
Network  State"  cell. 


Change  the  second  paragraph  to:  "The  maximum 
length  of  this  information  element  is  18  octets." 

Delete  the  following  rows: 

•  "Oil  network  specific  number"; 

•  "111  reserved  for  extension". 

Change  the  end  of  Note  2  to:  "this  information 
element  cannot  be  used  in  combination  with  Operator 
System  Access  or  Transit  Network  Selection 
information  elements." 

Delete  Note  4. 


Delete  the  following  rows: 

•  "0011  data  numbering  plan"; 

•  "0100  telex  numbering  plan"; 

•  "1111  reserved  for  extension". 

Change  "c)"  under  the  Note  to:  "this  information 
element  cannot  be  used  in  combination  with  Operator 
System  Access  or  Transit  Network  Selection 
information  elements." 

Add  Attachment  B  of  this  document  after  the 
following: 

"Number  digits  (octets  4,  etc.) 

This  field  is  coded  with  ASCII  characters, 
according  to  the  formats  specified  in  the  appropriate 
numbering/dialing  plan." 

Change  the  second  paragraph  from  "The  maximum 
length  of  this  information  element  is  network 
dependent."  to  "The  maximum  length  of  this 
information  element  is  19  octets." 
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Section  4.5.9 

Calling  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.9 

Calling  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.9 
Calling  party  number 

Numbering  Plan  Identification  (octet  3)  coding 

Section  4.5.9 
Calling  party  number 


Section  4.5.11 
Cause 


Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Recommendation  (octet  3a)  coding 

Section  4.5.11 
Cause 


Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 


Delete  the  following  rows: 

•  "Oil  network  specific  number"; 

•  "111  reserved  for  extension". 

Delete  Note  4. 


Delete  the  following  rows: 

•  "0100  telex  numbering  plan"; 

•  "1111  reserved  for  extension". 

Add  Attachment  C  of  this  document  after  the 
following: 

"Number  digits  (octets  4,  etc.) 

This  field  is  coded  with  ASCII  characters, 
according  to  the  formats  specified  in  the  appropriate 
numbering/dialing  plan." 

Change  the  second  sentence  of  the  first  paragraph  to: 
"The  maximum  length  of  this  information  element  is 
10  octets." 

Change  octet  3,  bit  8  from  "0/1"  to  "1". 


Delete  octet  3a. 


Delete  the  Note  under  the  figure. 


Delete  this  coding  and  Notes  1  and  2. 


Add  the  following  sentence  to  the  end  of  the 
paragraph  following  "Diagnostics  (octet  5)":  "If  more 
than  one  IE  is  identified  in  a  diagnostic,  they  should 
be  ordered  as  IEs  normally  appear  in  a  message." 

Change  the  "unallocated  (unassigned)  number/ 
diagnostics"  cell  to  "Not  used". 


Change  the  "no  route  to  specified  transit  network/ 
diagnostics"  cell  to  "Not  used". 
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Section  4.5.11 
Cause 
Cause  table 


Change  the  "no  route  to  destination/diagnostics"  cell 
to  "Not  used". 


Section  4.5.11 
Cause 
Cause  table 


Change  "normal  call  clearing/diagnostics"  cell  to  "Not 
used". 


Section  4.5.11 
Cause 
Cause  table 


Change  the  "user  busy/diagnostics"  cell  to  "(see  Note 
10)". 


Section  4.5.11 
Cause 
Cause  table 


Change  the  "call  rejected/diagnostics"  cell  to  "Not 
used". 


Section  4.5.11 
Cause 
Cause  table 


Delete  the  "number  changed/diagnostics"  cell. 


Section  4.5.11 
Cause 
Cause  table 


Section  4.5.11 
Cause 
Cause  table 


Delete  the  following  rows: 

•  "non-selected  user  clearing"; 

•  "network  out  of  order"; 

•  "resource  unavailable,  unspecified"; 

•  "quality  of  service  unavailable"; 

•  "only  restricted  digital  information  bearer  capability 
is  available"; 

•  "service  or  option  not  implemented,  unspecified"; 

•  "invalid  transit  network  selection"; 

•  "invalid  message,  unspecified". 

Change  the  "No  circuit/channel  available/diagnostics" 
cell  to  "(see  Note  10)". 


Section  4.5.11 
Cause 
Cause  table 


Delete  reference  to  "(see  Note  6)"  in  the  "access 
information  discarded/diagnostics"  cell. 


Section  4.5.11 
Cause 
Cause  table 


Add  "(see  Note  10)"  to  the  "requested  circuit  or 
channel  not  available/diagnostics"  cell. 


Section  4.5.11 
Cause 
Cause  table 


Delete  the  corresponding  cell  in  the  "diagnostics" 
column  for  the  following  rows: 

•  "requested  facility  not  subscribed"; 

•  "bearer  capability  not  authorized"; 

•  "bearer  capability  not  presently  available"; 

•  "channel  type  not  implemented"; 

•  "requested  facility  not  implemented". 
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Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 


Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 

Figure  18  —  Coding  of  the  diagnostic  field  for  causes 
57,  58  and  65. 

Section  4.5.11 
Cause 

Section  4.5.12 
Channel  identification 


Section  4.5.12 
Channel  identification 


Change  the  "bearer  capability  not  implemented/ 
diagnostics"  cell  to  "Not  used". 

Change  the  "identified  channel  does  not  exist/ 
diagnostics"  cell  to  "Not  used". 


Delete  the  "incompatible  destination/diagnostics"  cell. 


Delete  the  reference  to  "(see  Note  6)"  in  the 
"mandatory  information  element  is  missing/ 
diagnostics"  cell. 

Change  the  "information  element  non-existent  or  not 
implemented/diagnostics"  cell  to  "Information 
element  identifier(s)  (see  Note  8)". 


Change  the  "invalid  information  element  contents/ 
diagnostics"  cell  to  "Information  element 
identifier(s)". 

Change  the  "recovery  on  timer  expiry/diagnostics" 
cell  to  "Not  used". 


Delete  the  following  Notes:  2,  3, 4, 5, 6,  7, 9, 1 1, 12. 


Delete  this  figure  and  Notes  1  and  2  appearing  below 
it. 


Delete  all  text  referring  to  octets  5  (attribute  number), 
5a  (rejected  attribute),  and  5b  (available  attribute). 

Change  the  last  sentence  in  the  first  paragraph  to: 
"The  default  maximum  length  for  this  information 
element  is  6  octets." 

Delete  the  second  paragraph. 
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Section  4.5.12  Change  octet  3.1,  bit  8  from  "0/1"  to  "1". 

Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Section  4.5.12  Delete  the  reference  to  "Note  2"  of  octet  3.2. 

Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Section  4.5.12  Delete  the  references  to  "(Note  2)"  and  "Note  4"  in 

Channel  identification  octet  3.3. 

Figure  19  —  Channel  identification  information 
element 

Section  4.5.12  Delete  the  last  sentence  of  Note  1. 

Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Section  4.5.12  Delete  Notes  2  and  4. 

Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Section  4.5.12 
Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Add  the  following  to  the  end  of  Note  3:  "For 
completeness,  a  pointer  to  slot  map  is  shown.  It  is 
not  supported  for  this  IA." 


Section  4.5.12 

Channel  identification 

Interface  identifier  present  (octet  3)  coding 

Section  4.5.12 
Channel  identification 
Interface  type  (octet  3)  coding 


Change  row  the  last  row  ("1")  to:  "1  Interface 
explicitly  identified  in  octet  3.1." 


Delete  the  following  row:  "0  basic  interface". 


Section  4.5.12 
Channel  identification 

Information  channel  selection  (octet  3)  coding 

Section  4.5.12 
Channel  identification 

Information  channel  selection  (octet  3)  coding 


Delete  the  column  "basic  interface". 


Delete  the  last  two  rows  ("10"  and  "11"). 


Section  4.5.12  Delete  Note  3. 

Channel  identification 

Information  channel  selection  (octet  3)  coding 
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Section  4.5.12 

Channel  identification 

Interface  identifier  (octet  3.1)  coding 

Section  4.5.12 

Channel  identification 

Coding  standard  (octet  3.2)  coding 

Section  4.5.12 
Channel  identification 
Number/map  (octet  3.2)  coding 

Section  4.5.12 
Channel  identification 

Channel  type/map  element  type  (octet  3.2)  coding 

Section  4.5.12 
Channel  identification 

Channel  type/map  element  type  (octet  3.2)  coding 

Section  4.5.12 
Channel  identification 

Section  4.5.12 
Channel  identification 


Section  4.5.13 
Connected  number 

Section  4.5.14 
Connected  subaddress 

Section  4.5.15 
Display 

Section  4.5.16 

High  layer  compatibility 

Section  4.5.17 
Keypad  facility 

Section  4.5.18 

Low  layer  compatibility 

Section  4.5.18 

Low  layer  compatibility 

Negotiation  indicator  (octet  3a)  coding 


Delete  the  second  sentence  ("At  subscription  time 
..."). 


Delete  row  "  1  0  National  Standard  ..." 


Delete  the  last  row. 


Delete  the  last  three  rows. 


Delete  the  Note. 


Delete  all  text  and  Figure  20  referring  to  "Slot  map 
(octet  3.3)". 

Add  the  following  at  the  end  of  the  section:  "Note  — 
In  the  network  to  user  direction  (n  ->  u),  the 
terminating  PRI  will  allow  channel  negotiation.  The 
network  will  support  offering  calls  with  preferred  B- 
channel  and  the  user  responds  specifying  the  channel 
to  be  used  for  the  call." 

Delete  this  section. 


Delete  this  section. 


Delete  this  section. 


Change  the  second  paragraph  to:  "The  maximum 
length  of  this  information  element  is  five  octets." 

Delete  this  section. 


Delete  the  second  paragraph. 


Delete  the  last  row. 
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Section  4.5.18 

Low  layer  compatibility 

Negotiation  indicator  (octet  3a)  coding 

Section  4.5.18 

Low  layer  compatibility 

User  information  layer  3  protocol  (octet  7)  coding 


Delete  Note  1. 


Change  "ANSI  T1.607"  to  "NIU  90-302"  in  the  first 
row. 


Section  4.5.19 
Network-specific  facilities 


Section  4.5.19 
Network-specific  facilities 

Section  4.5.19 
Network-specific  facilities 

Section  4.5.20 
Notification  indicator 


Change  the  second  sentence  of  the  first  paragraph  to: 
"No  more  than  two  Network-specific  facilities 
information  elements  may  be  included  in  a  single 
message." 

Change  the  second  paragraph  to:  "The  maximum 
length  of  this  information  element  is  32  octets." 

Add  Attachment  D  of  this  document  to  the  end  of  this 
section. 

Delete  this  section. 


Section  4.5.21 
Progress  indicator 

Progress  description  (octet  4)  coding 

Section  4.5.21 
Progress  indicator 


Delete  row 
ISDN." 


*000  0100  4   call  has  returned  to  the 


Section  4.5.22 
Repeat  Indicator 

Section  4.5.24 
Signal 

Section  4.5.25 

Transit  network  selection 


Add  the  following  Note  after  Notes  1  and  2  following 
the  "Progress  description  (octet  4)"  coding:  "3  In 
the  SETUP  message,  in  the  user  to  network  direction 
(u  ->  n)  on  PRI,  one  of  two  values  may  be  used  in 
the  progress  description  field:  'call  is  not  end-to-end 
ISDN'  (1),  or  'calling  equipment  is  non-ISDN'  (3). 
In  the  SETUP  message,  in  the  network  to  user 
direction  (n  ->  u)  on  PRI,  one  of  two  values  may  be 
used  in  the  progress  description  field:  'call  is  not 
end-to-end  ISDN'  (1),  or  'calling  equipment  is  non- 
ISDN'  (3)." 

Delete  this  section. 


Delete  this  section. 


Change  the  first  paragraph  to:  "The  purpose  of  the 
Transit  network  selection  information  element  is  to 
identify  one  requested  transit  network  (See  Annex 
Q." 


NIU-Forum  Agreements  On  ISDN 


B-21 


Section  4.5.25 

Transit  network  selection 


Section  4.5.25 

Transit  network  selection 

Type  of  network  identification  (octet  3)  coding 

Section  4.5.25 

Transit  network  selection 

Network  identification  plan  (octet  3)  coding 

Section  4.5.26 
User-user 


Section  4.5.26 
User-user 

Protocol  discriminator  (octet  3)  coding 
Section  5 

Circuit-switched  call  control  procedures 


Section  5 

Circuit-switched  call  control  procedures 


Section  5.1 

Call  establishment  at  the  originating  interface 

Section  5.1.1 
Call  request 


Section  5.1.1 
Call  request 


Section  5.1.1 
Call  request 


Section  5.1.1 
Call  request 


Change  the  second  paragraph  to:  "The  default 
maximum  length  of  this  information  element  is  7 
octets." 

Delete  the  last  row  ("Oil  ..."). 


Delete  the  last  row  ("0011  ..."). 


Add  the  following  to  the  end  of  the  first  paragraph: 
"This  IE  is  to  be  included  based  on  the  User-to-user 
supplementary  service  description  and  user 
application." 

Change  "ANSI  T1.607"  to  "NIU  90-302"  in  the  last 
row  of  the  coding. 

Change  the  third  paragraph  ("All  messages  ...")  to: 
"All  messages  in  this  standard  contain  the  functional 
type  of  information  elements.  Functional  information 
elements  are  characterized  as  requiring  a  degree  of 
intelligent  processing  by  the  Customer  Premise 
Equipment  (CPE)  in  either  their  generation  or 
analysis." 

Delete  the  fifth  paragraph  ("As  a  general  ..."),  the 
second  Note  of  the  section,  and  the  seventh 
paragraphs  ("In  addition  ..."). 

Change  "ANSI  T1.602"  to  "NIU  89-210"  in  the  last 
sentence. 

Change  the  last  sentence  of  the  first  paragraph  to: 
"The  Bearer  capability  information  element  is 
mandatory  in  the  SETUP  message." 

Change  the  third  paragraph  to:  "Furthermore,  the 
SETUP  message  shall  also  contain  all  of  the  call 
information  (i.e.,  address  and  facility  requests) 
necessary  for  call  establishment." 

Delete  the  following  from  the  fourth  paragraph:  "b) 
the  Keypad  information  ...  other  call  information", 
and  the  Note  ("All  networks  are  ..."). 

Delete  the  last  paragraph  ("For  overlap  ..."). 
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Section  5.1.2 

B -channel  selection  —  originating 


Delete  the  following  from  the  first  paragraph:  "c)  any 
channel  ...  alternative  c)  is  assumed." 


Section  5.1.2 

B -channel  selection  —  originating 
Section  5.1.2 

B-channel  selection  —  originating 


Section  5.1.2 

B-channel  selection  —  originating 


Delete  the  last  sentence  from  the  third  paragraph: 
case  c),  the  ...  with  the  D-channel." 


"In 


Section  5.1.2 

B-channel  selection  —  originating 


Change  the  end  of  the  first  sentence  in  the  fourth 
paragraph  from  "(i.e.,  a  SETUP  ACKNOWLEDGE  or 
CALL  PROCEEDING  message)."  to  "(i.e.,  a  CALL 
PROCEEDING  message)." 

Change  the  fifth  paragraph  to:  "The  user  need  not 
attach  until  receiving  a:  a)  CALL  PROCEEDING,  b) 
ALERTING  message  with  the  progress  indicator  8 
'in -band  information  or  appropriate  pattern  is  now 
available'  or  c)  a  PROGRESS  message  with  the 
progress  indicator  1  'call  is  not  end-to-end  ISDN; 
further  call  progress  information  may  be  available  in- 
band'.  Prior  to  this  time,  the  network  cannot  assume 
that  the  user  has  attached  ...  (if  it  has  not  already 
done  so)." 

Change  the  first  sentence  of  the  last  paragraph  to: 
"In  case  a),  if  the  specified  channel  is  not  available, 
and  in  case  b)  if  not  channel  is  available,  a 
RELEASE  COMPLETE  message  with  a  cause  value 
of  44  'requested  circuit/channel  not  available'  or  34 
'no  circuit/channel  available',  respectively,  is  sent  by 
the  network  as  described  in  5.3." 


Section  5.1.3 
Overlap  sending 

Section  5.1.4 

Invalid  call  information 


Section  5.1.4 

Invalid  call  information 


Delete  this  section. 


Change  the  first  sentence  in  the  first  paragraph  to: 
"If,  following  the  receipt  of  the  SETUP  message,  the 
network  determines  ...  cause  such  as  the  following:". 

Add  the  following  to  the  end  of  the  first  paragraph 
after  "28  ...":  "82  'identified  channel  does  not  exist'." 


Section  5.1.5.1 

Call  proceeding,  en-bloc  sending 
Section  5.1.5.2 

Call  proceeding,  overlap  sending 
Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 


Add  the  following  to  the  second  paragraph  after  "58 
"34  'no  circuit/channel  available'." 

Delete  this  section. 


Change  "a)  ..."  in  the  first  paragraph  to:  "a)  in  an 
appropriate  call  control  message  when  a  state  change 
is  required  (CONNECT);  or,". 
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Section  5.1.6 
Notification  of 
interface 


interworking  at  the  originating 


Add  to  the  end  of  "1  ..."  in  the  second  paragraph 
"(i.e.,  in  a  PROGRESS  message);  or,". 


Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 

Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 

Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 

Section  5.1.7 

Call  confirmation  indication 


Section  5.2 

Call  establishment  at  the  destination  interface 

Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 


Section  5.2.1 
Incoming  call 


Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 


Change  "2  ..."  in  the  second  paragraph  to:  "2 
'destination  address  is  non-ISDN'  (i.e.,  in  a 
CONNECT  message);". 

Delete  "4  ...  end-to-end  ISDN"  from  the  second 
paragraph. 

Delete  "or  more"  from  the  second  part  of  the  first 
sentence  in  the  fourth  paragraph. 

Change  the  last  sentence  in  the  first  paragraph  to: 
"When  the  user  receives  the  ALERTING  message,  the 
user  shall  enter  the  Call  Delivered  state." 

Delete  the  last  sentence  of  the  third  paragraph  ("No 
use  ..."). 

Delete  the  last  two  sentences  of  the  first  paragraph. 


Change  the  last  part  of  the  second  paragraph  from 
"(e.g.,  Display,  Low  layer  compatibility)."  to  "(e.g., 
Low  layer  compatibility.)". 

Add  the  following  to  the  end  of  the  second  paragraph: 
"In  general,  a  call  terminating  from  a  non-ISDN  line 
or  from  a  Public  Switched  Telephone  Network 
(PSTN)  trunk  should  be  offered  to  the  called  user 
equipment  with  the  3.1  kHz  audio  bearer  capability." 

Delete  the  first  and  second  sentences  of  the  third 
paragraph.  Delete  "However,  if...  the  interface"  from 
the  third  sentence.  The  third  paragraph  will  now 
read:  "A  point-to-point  data  link  shall  be  used  to 
carry  the  SETUP  message.  After  sending  the  SETUP 
message,  the  network  starts  timer  T303." 

Delete  the  fifth  paragraph  and  the  Note  following  this 
paragraph. 

Change  the  second  part  of  the  last  sentence  in  the 
seventh  paragraph  from  "timers  T303  and  T312  are 
restarted."  to  "timer  303  is  restarted." 
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Section  5.2.2 
Compatibility  checking 

Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 
Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 
Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 


Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 


Section  5.2.3.2 

SETUP  message  delivered  by  broadcast  data  link 

Section  5.2.5.1 

Response  to  en-bloc  SETUP 


Section  5.2.5.1 

Response  to  en-bloc  SETUP 

Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 
Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 


Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 


Delete  the  second  paragraph  ("When  the  SETUP 
message  ..."). 

Delete  the  following  from  the  first  paragraph  under 
"a) "3)  any  channel  is  acceptable." 

Delete  the  paragraph  under  "b)  that  reads  "In  case 
3),  ...." 

Change  the  first  sentence  in  the  third  paragraph  under 
"b)"  to:  "If  in  case  1)  the  B-channel  indicated  in  the 
first  response  message  is  not  the  channel  offered  by 
the  network,  or  in  case  2)  the  B-channel  indicated  in 
the  first  response  message  is  unacceptable  to  the 
network,  it  will  clear  the  call  by  sending  a  RELEASE 
message  with  cause  6  'channel  unacceptable'  (see 
5.3.2  d)." 

Change  the  first  part  of  "e)  ..."  to:  "e)  In  case  1)  if 
the  indicated  B-channel  is  not  available,  or  in  case  2) 
if  no  B-channel  is  available 

Delete  this  section. 


Change  the  first  sentence  of  the  Note  to:  "A  Progress 
indicator  information  element  may  be  included  in  a 
CONNECT  message  (e.g.,  when  an  analogue  terminal 
is  connected  to  an  NT2  functional  grouping)." 

Delete  the  second  paragraph  ("When  the  SETUP 
message  was  delivered  via  a  broadcast ..."). 

Delete  the  first  paragraph  ("When  the  SETUP 
message  is  delivered  on  a  broadcast ..."). 

Change  the  second  paragraph  to:  "Upon  receipt  of 
the  first  CALL  PROCEEDING  message  from  a  user, 
the  network  shall:  stop  timer  T303;  start  time  T310; 
and  enter  the  incoming  Call  Proceeding  state." 

Delete  the  fourth  paragraph  ("When  the  SETUP 
message  was  delivered  via  a  broadcast ..."). 


NIU-Forum  Agreements  On  ISDN 


B-25 


Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 


Change  the  fifth  paragraph  to:  "Upon  receipt  of  the 
ALERTING  message  from  a  user,  the  network  shall: 
stop  timers  T303  or  T310  (if  running)  and  TDEL  (if 
running);  start  optional  timer  T301  (unless  another 
internal  alerting  supervision  timer  function  exists;  w.g. 
incorporated  in  call  control);  enter  the  Call  Received 
state;  and  send  a  corresponding  ALERTING  message 
to  the  calling  user." 


Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 


Delete  the  sixth  paragraph  ("When  a  SETUP  message 
has  been  delivered  on  a  broadcast  link  ..."). 


Section  5.2.5.3 

Called  user  clearing  during  Incoming  call 
establishment 


Change  the  first  part  of  the  first  paragraph  to:  "If  the 
RELEASE  COMPLETE  or  DISCONNECT  message 
is  received 


Section  5.2.5.3 

Called  user  clearing  during  Incoming  call 
establishment 


Delete  the  second  and  third  paragraphs. 


Section  5.2.5.3.1 

DISCONNECT  received  prior  to  expiry  of  T312 


Delete  this  section. 


Section  5.2.5.3.2 

DISCONNECT  received  after  expiry  of  timer  T312 


Delete  this  section. 


Section  5.2.5.4 
Call  failure 


Delete  the  following  from  the  first  paragraph:  "a)  If 
the  SETUP  message  ...  Call  Abort  state;" 


Section  5.2.5.4 
Call  failure 


Change  "b)"  in  the  first  paragraph  to:  "b)  The 
network  shall  also  initiate  clearing  procedures  toward 
the  called  user  in  accordance  with  5.3.4,  using  cause 
102  'recovery  on  timer  expiry'." 


Section  5.2.5.4 
Call  failure 


Delete  the  second  paragraph  ("If  the  network  receives 
..."). 


Section  5.2.5.4 
Call  failure 


Delete  the  following  from  the  third  paragraph:  "a)  If 
the  SETUP  ...  shall  be  sent." 


Section  5.2.5.4 
Call  failure 


Change  "b)"  in  the  third  paragraph  to:  "b)  The  called 
user  shall  be  cleared  in  accordance  with  5.3.4,  using 
cause  102  'recovery  on  timer  expiry'." 


Section  5.2.5.4 
Call  failure 


Change  the  beginning  of  the  first  sentence  in  the 
fourth  paragraph  to:  "If  the  network  supports  timer 
T301  and  has  received  a  ALERTING  message, 


Section  5.2.5.4 
Call  failure 


Delete  from  the  fourth  paragraph:  "a)  If  the  SETUP 
message  was  ...  shall  be  sent." 
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Section  5.2.5.4 
Call  failure 

Section  5.2.6 

Notification  of  interworking  at  the  terminating 
interface 


Section  5.2.6 

Notification  of  interworking  at  the  termination 
interface 

Section  5.2.7 
Call  accept 


Section  5.2.8 
Active  indication 

Section  5.2.9 

Non-selected  user  clearing 

Section  5.3.2 
Exception  conditions 


Section  5.3.2 
Exception  conditions 

Section  5.3.2 
Exception  conditions 

Section  5.4 

In-band  tones  and  announcements 


Change  "b)"  in  the  fourth  paragraph  to:  "b)  The 
called  user  shall  be  cleared  in  accordance  with  5.3.4, 
using  cause  102  'recovery  on  timer  expiry'." 

Change  the  first  item  in  the  list  in  the  second 
paragraph  from:  " —  in  an  appropriate  ..."  to:  " —  in 
an  appropriate  call  control  message  when  a  state 
change  is  required  (CONNECT);  or,". 

Delete  the  third  item  from  the  list  in  the  third 
paragraph:  "4     Call  has 


Add  the  following  to  the  end  of  the  last  paragraph: 
"If  the  CONNECT  message  is  the  first  response  to  the 
SETUP  message,  it  shall  contain  the  channel 
identification  information  element." 

Delete  the  fourth  paragraph  ("A  user  that  has  received 
the  SETUP  via  the  broadcast  data  link  ..."). 

Delete  this  section. 


Change  in  the  first  paragraph  "a)"  to:  "a)  In  response 
to  a  SETUP  message,  the  user  or  network  can  reject 
a  call  (e.g.,  because  of  the  unavailability  of  a  suitable 
B-channel)  by:  responding  with  a  RELEASE 
COMPLETE  message  provided  no  other  response  has 
previously  been  sent  releasing;  the  call  reference  and 
entering  the  Null  state." 

Delete  from  the  first  paragraph:  "b)  In  the  case  ... 
user  clearing". 

Delete  from  the  first  paragraph  e)l)  and  e)2)  and  the 
Note  at  the  end  of  the  section. 

Change  the  title  of  this  section  to  "In-band  audible 
ringing  tone  and  announcements". 
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Section  5.4 

In-band  tones  and  announcements 


Change  the  first  paragraph  to:  "It  is  assumed  that  the 
originating  Class  II  device  will  provide  a  busy  tone 
and  a  reorder  tone  to  the  calling  user  for  speech  and 
3.1  kHz  calls.  The  network  will  not  provide  in-band 
busy  or  reorder  tone.  When  in-band  audible  ringing 
tone/announcements  not  associated  with  a  call  state 
change  are  to  be  provided  by  the  network  before 
reaching  the  Active  state,  a  PROGRESS  message  is 
returned  simultaneously  with  the  application  of  the  in- 
band  audible  ringing  tone/announcement.  The 
PROGRESS  message  contains  the  progress  indicator 
8  'in-band  information  or  appropriate  pattern  is  now 
available'." 


Section  5.4 

in-band  tones  and  announcements 


Change  the  second  paragraph  to:  "When  an  audible 
ringing  tone  has  to  be  provided  together  with  a  ...  is 
sent  simultaneously  with  the  application  of  the  inband 
audible  ringing  tone." 


Section  5.4 

in-band  tones  and  announcements 


Delete  Note  1. 


Section  5.4 

in-band  tones  and  announcements 


Change  Note  2  to:  "When  the  PROGRESS  message 
is  used,  the  user  may  initiate  call  clearing  as  a  result 
of  the  applied  in-band  audible  ringing  tone/ 
announcement,  according  to  procedures  specified  in 
5.3.3." 


Section  5.5 
Restart  procedure 


Delete  from  the  second  paragraph  "b)  the  interface  is 
a  ...  exists;  or,". 


Section  5.5.2 
Receipt  of  RESTART 


Change  in  Note  2  the  reference  to  "ANSI  T1.602"  to 
"NIU  89-210". 


Section  5.5.2 
Receipt  of  RESTART 


Change  in  Note  2  "b)"  to:  "b)  that  correspond  to  the 
specified  channel  or  interface." 


Section  5.7 
Call  collisions 


Delete  the  Note  at  the  end  of  the  section. 


Section  5.8.2 
Message  too  short 


Change  this  paragraph  to:  "When  a  message  is 
received  that  is  too  short  (less  than  4  octets)  to 
contain  a  complete  message  type  information  element, 
that  message  shall  be  ignored." 


Section  5.8.4 

Message  type  or  message  sequence  errors 


Add  the  following  after  the  first  paragraph:  "The 
NOTIFY  message  may  be  ignored  by  the  recipient." 


Section  5.8.7.2 

Non-mandatory  information  element  content  error 


Delete  the  last  sentence  of  the  second  paragraph 
("However,  in  some  ..."). 
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Section  5.8.8 
Data  link  reset 

Section  5.8.9 
Data  link  failure 

Section  5.8.9 
Data  link  failure 

Section  5.9 

User  notification  procedure 
Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side  (Part  2) 

Annex  A  —  SDL  diagrams 


Delete  from  the  first  paragraph:  "a)  For  calls  in  the 
Overlap  ...  procedures  of  5.3". 

Delete  from  the  first  paragraph  the  first  sentence  of 
"a)  ..."  ("The  calls  in  the  ...  internally."). 

Delete  the  second  sentence  of  the  Note  following  the 
first  paragraph  ("Note  —  If  the  transfer  mode  ...."). 

Delete  this  section. 


Delete  row  "T302". 


Delete  the  second  sentence  in  the  "T310/NORMAL 
STOP"  cell  ("If  DISCONNECT  ..."). 


Delete  rows  "T312"  and  "T321". 


Delete  Notes  4  and  5. 


Add  the  following  to  the  end  of  Note  6:  "(see  Annex 
D)". 


Delete  the  following  rows: 

•  "T301"; 

•  "T304". 

Delete  "SETUP  ACKNOWLEDGE"  from  the  "T303/ 
NORMAL  STOP"  cell. 


Delete  the  reference  to  "Note  4"  in  the  "T310/TIMER 
NUMBER"  cell. 


Delete  Notes  3  and  4. 


Delete  this  section.  NOTE:  This  section  has  not 
been  addressed. 
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Section  B.3.1 

Compatibility  checking  with  addressing  information 

Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capability  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 

Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capability  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 

Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Section  B.3.4 
User  action  figures 

Annex  C,  Section  C.l 
Introduction 

Annex  C,  Section  C.2 
Selection  Not  Supported 

Annex  C,  Section  C.3 
Selection  Supported 


Annex  C,  Section  C.3 
Selection  Supported 

Annex  C,  Section  C.3 
Selection  Supported 

Annex  C,  Section  C.3 
Selection  Supported 


Annex  D 

Extensions  for  Symmetric  Call  Operation 


Delete  Note  2  ("If  an  incoming  call,  ...  or 
subaddress."). 

Delete  the  reference  to  "(Note  1)"  from  the  cell  in  the 
first  row  of  the  second  column. 


Delete  the  "broadcast  data  link"  column. 


Delete  the  reference  for  "(Note  1)"  in  the  cells  in  the 
first  row  of  the  second  and  third  columns. 


Delete  Notes  1  and  3  (ed.  note:  Note  3  is  still 
referenced  in  the  figures). 

Delete  "optional"  from  the  first  paragraph. 
Delete  this  section. 


Change  the  first  paragraph  to:  "The  user  identifies 
the  selected  transit  network  in  the  SETUP  message. 
One  Transit  network  selection  information  element  is 
used  to  convey  a  single  network  identification." 

Delete  the  second  ("The  user  may  ..."),  third  ("As  the 
call  ..."),  and  fourth  ("No  more  than  ...")  paragraphs. 

Delete  the  last  sentence  of  the  sixth  paragraph  ("The 
diagnostic  ..."). 


Delete  the  seventh  ("A  network  may  ...")  and  eighth 
("If  the  transit ...")  paragraphs. 

Delete  Annex  D  and  replace  with  Attachment  E  of 
this  document. 
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Annex  E,  Section  E.3 
Routing  Not  Supported 


Annex  E,  Section  E.4 
Routing  Supported 


Annex  E,  Section  E.4 
Routing  Supported 


Add  the  following  paragraph  before  at  die  end  of  this 
section:  "When  the  requested  facility  can  not  be 
provided  an  indication  shall  be  returned  in  the  first 
clearing  message  with  cause  29  'facility  rejected'." 

Change  the  first  sentence  in  the  fourth  paragraph  to: 
"No  more  than  two  Network-specific  facilities 
information  elements  may  be  used  in  a  SETUP 
message." 

Delete  the  last  sentence  of  the  fifth  paragraph  ("The 
diagnostic  ..."). 


Annex  F 

D-channel  Backup  Procedure 


Delete  this  Annex. 


Annex  G,  Section  G.l 
Introduction 


Add  the  following  to  the  end  of  the  first  paragraph: 
"Section  4.5.11  identifies  the  causes  supported  in  NIU 
90-302." 


Annex  G,  Section  G.3.8 

Cause  46  "precedence  call  blocked" 

Annex  H,  Section  H.l 
Introduction 


Change  "precedence  circuits"  to  "preemptable 
circuits". 

Change  the  first  paragraph  to:  "These  are  the  only 
recognized  codings  of  the  following  information 
elements." 


Annex  H,  Section  H.l 
Introduction 

Annex  H 

Examples  of  Information  Elements  Coding 


Delete  the  last  two  bullet  items  from  the  second 
paragraph. 

Delete  the  following  figures  and  sections: 

•  Figure  "H.3  Coding  for  7kHz  Audio"; 

•  Figure  "H.6  Coding  for  synchronous  1472  kbit/s"; 

•  Section  H.3  Channel  identification  information 
element; 

•  Section  H.4  Called  and  Calling  party  subaddress 
information  element. 


Annex  I 

Use  of  Progress  indicators 
Annex  I 

Use  of  Progress  indicators 
Annex  I 

Use  of  Progress  indicators 
Annex  M 

Low  Layer  Compatibility  Negotiation 


Delete  the  fifth  paragraph  ("Progress  indicator  4  ..."). 


Delete  "or  basic"  from  the  left  side  of  Figure  1.1 
(between  the  TE  and  ISDN). 

Delete  "or  basic"  from  the  right  side  of  Figure  1.1 
(between  ISDN  and  NT2). 

Delete  this  Annex. 
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Annex  N 

Procedures  for  Establishment  of  Bearer  Connection 
Prior  to  Call  Acceptance 

Annex  O 

Optional  Procedures  for  Bearer  Service  Change 

Annex  P,  Section  P.l 
Introduction 

Annex  P,  Section  P.l 
Introduction 


Annex  P,  Section  P.l 
Introduction 


Annex  P,  Section  P.2 

Operator  system  access  requested  in  Keypad  facility 
information 

Section  P.4 
invalid  request 

Annex  Q 

Responding  address  requirements  of  the  OSI  network 
layer  service 


Delete  this  Annex  and  replace  with  Attachment  F  of 
this  document. 


Delete  this  Annex. 


Delete  "optional"  from  the  first  sentence  in  the  first 
paragraph. 

Change  the  last  sentence  of  the  first  paragraph  to: 
"These  procedures  apply  to  the  speech,  and  3.1  kHz 
and  audio  bearer  services." 

Change  the  second  paragraph  to:  "The  user  may 
indicate  a  request  for  access  to  an  operator  or 
attendant  system  using  the  Operator  system  access 
information  element." 

Delete  this  section. 


Delete  this  section. 


Delete  this  Annex. 
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Attachment  A 

(of  Appendix  B) 

1.  General 

1 .1  Scope  and  Purpose 

This  Implementation  Agreement  specifies  a  minimal  subset  of  procedures  and  codepoints  from  the  American  National 
Standards  Tl. 607- 1990  (Ref.  [17])  for  the  establishment,  maintenance,  and  clearing  of  ISDN  connections  at  the  user- 
to-network  interface.  This  signalling  standard  is  used  to  support  the  circuit-switched  bearer  services  specified  in  ANS 
Tl.604-1990*. 

Terminals  are  not  required  to  support  all  services.  Switches  will  support  all  of  the  mandatory  protocols  and 
codepoints  in  this  implementation  agreement.  This  does  not  preclude  the  support  of  additional  services  and 
procedures.  However,  equipment  must  be  able  to  interoperate  with  equipment  supporting  only  this  minimal  subset. 

1.1.1  Definitions 

The  ANS  Tl.607-1990  (Ref.  [17])  assumes  that  procedures  apply  generically  to  ISDN  access  interfaces,  i.e.,  the 
document  does  not  distinguish  between  basic  and  primary  rates  access  interfaces.  In  addition,  there  are  no  references 
to  specific  applications  in  that  document  The  concept  of  equipment  classes  is  introduced  in  this  document  to  permit 
certain  procedures  to  be  associated  with  a  particular  application  or  class  of  equipment,  e.g.,  station  equipment  versus 
PBX.  Specifically,  two  classes  of  equipment  are  defined  on  the  basis  of  two  fundamental  attributes. 

The  first  attribute  relates  to  the  possibility  of  an  exchange  of  signals  occurring  beyond  the  public  network's  point 
of  contact  with  the  interface  (i.e.,  between  the  equipment  directly  connected  to  the  public  network  and  ISDN 
terminals  or  telephones  connected  to  that  equipment).  For  example,  some  user  equipment  may  support  subtending 
Basic  Access  digital  subscriber  loops  and/or  analog  telephone  loops.  For  Class  I  equipment,  the  network  makes  no 
provision  for  such  an  arrangement  and  assumes  the  Class  I  equipment  constitutes  the  endpoint  of  the  communication. 
Conversely,  in  the  case  of  Class  II  equipment,  the  procedures  at  the  network  take  into  account  that  communication 
between  Class  II  equipment  (with  which  it  communicates  directly)  and  other  equipment  (with  which  the  network  does 
not  have  direct  contact)  may  occur.  As  an  example,  Class  II  equipment  may  support  digital  and/or  analog  subscriber 
loops.  Use  of  Class  II  equipment  also  involves  the  possibility  of  having  interworking  occur  beyond  the  equipment 
with  which  the  network  has  direct  contact  Therefore,  it  is  reasonable  for  Class  II  equipment  to  provide  the  network 
with  an  interworking  notification,  for  both  outgoing  and  incoming  calls,  when  either  the  calling  or  called  party 
respectively,  is  a  non-ISDN  user.  Class  II  equipment  may  also  send  an  interworking  notification  if  a  private  network 
exists  beyond  the  Class  II  equipment  and  interworking  to  a  non-ISDN  facility  within  that  network  takes  place.  When 
an  interface  is  associated  with  Class  I  equipment,  it  is  assumed  the  multiple  pieces  of  equipment  may  exist  and 
communicate  with  the  network  over  the  D-channel.  However,  in  this  case,  all  equipment  is  assumed  to  be  ISDN- 
capable  and  is  considered  as  the  endpoint  of  the  communication.  Therefore,  interworking  notification  should  not  be 
accepted  from  Class  I  equipment. 

The  second  attribute  relates  to  the  manner  in  which  a  SETUP  message  should  be  presented  to  the  user  equipment. 
When  Class  I  equipment  is  applied  on  a  particular  interfaces,  the  network  should  broadcast  the  SETUP  message 
associated  with  each  call  that  terminates  on  that  interface,  since  interaction  between  the  network  and  multiple  pieces 
of  user  equipment  should  be  supported.  On  the  other  hand,  the  network  should  not  broadcast  SETUP  messages 
associated  with  terminating  calls  to  an  interface  on  which  Class  II  equipment  is  being  used.  Here,  a  single  piece 
of  user  equipment  is  assumed  to  be  involved  in  all  communication  with  the  network. 


Subject  to  further  discussion. 
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To  the  extent  possible,  it  is  desirable  to  have  one  set  of  requirements  for  ISDN  call  control  apply  to  all  ISDN  user 
configurations.  However,  in  cases  for  which  integrated  procedures  are  not  appropriate,  the  call  control  procedures 
associated  with  Equipment  Class  I  will  differ  from  those  associated  with  Equipment  Class  II.  Unless  otherwise 
noted,  the  assumption  should  be  that  a  particular  procedure/capability  should  be  provided  for  both  classes  of 
equipment  on  both  basic  and  primary  rate  access.  However,  use  of  the  equipment  class  terminology  permits 
clarification  of  the  circumstances  under  which  a  certain  capability  should  be  available  (i.e.,  when  a  particular 
equipment  class  is  in  use).  It  also  permits  a  mechanism  for  indicating  that  a  particular  capability  applies  only  to  a 
subset  of  four  possible  configurations  which  are  labeled  as  follows. 


Class  I  Class  n 


IB 

IIB 

IP 

IIP 

In  other  words,  a  capability  that  applies  to  Class  I  equipment  may  be  provided  on  basic  access  interfaces  (IB)  and/or 
primary  rate  access  interfaces  (IP).  Similarly,  a  capability  that  applies  to  Class  II  equipment  may  be  provided  on 
basic  access  interfaces  (IIB)  and/or  primary  rate  access  interfaces  (HP). 

The  notation  shown  in  the  table  above  is  used  within  this  implementation  agreement  to  indicate  when  protocol  or 
procedures  are  only  expected  to  be  supported  for  a  particular  equipment  class  and/or  are  limited  to  a  particular  type 
of  interface,  i.e.,  basic  or  primary  rate  interface. 
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Attachment  B 

(of  Appendix  B) 

The  various  parts  of  the  called  party  number  information  element  should  be  coded  as  follows: 

—  Type  of  number  and  numbering  plan  (octet  3) 
Bits 

7  6  5  4  3  2  1  Meaning  

0  0  0  0  0  0  0  Unknown 

0  0  1  0  0  0  1      International  number  in  ISDN  numbering  plan  (Rec.  E.164) 

0  1  0  0  0  0  1      National  number  in  ISDN  numbering  plan  (Rec.  E.164) 

1  0  0  0  0  0  1     Local  (directory)  number  in  ISDN  numbering  plan  (Rec.  E.164) 

All  other  values  are  reserved 


—  Digits  (octet  4,  etc.) 

Bits 

7  6  5  4  3  2  1  Meaning 


0 

1 

1 

000 

0 

0 

0 

1 

1 

000 

1 

1 

0 

1 

1 

0  0  1 

0 

2 

0 

1 

1 

00  1 

1 

3 

0 

1 

1 

0  1  0 

0 

4 

0 

1 

1 

0  1  0 

1 

5 

0 

1 

1 

0  1  1 

0 

6 

0 

1 

1 

0  1  1 

1 

7 

0 

1 

1 

1  00 

0 

8 

0 

1 

1 

1  00 

1 

9 

All  other  values  are  reserved 

Digits  should  be  represented  by  IA5  characters  whose  encoding  is  shown  above. 

In  the  network  to  user  direction  (n  ->  u),  this  IE  will  be  always  signaled  in  the  SETUP  message,  and  public  network 
interfaces  will  use  only  one  codepoint:  local  number  in  ISDN.  For  private  networks,  this  IE  can  contain  the 
following  codepoints:  abbreviated  type  of  number,  and  private  numbering  plan,  and  extra  digits  such  A,  B,  C,  and 
D  (as  per  IA5). 
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Attachment  C 

(of  Appendix  B) 

The  various  parts  of  the  calling  party  number  information  element  should  be  coded  as  described  below. 

—  Type  of  number  and  numbering  plan  (octet  3)  follows: 
Bits 

7  6  5  4  3  2  1  Meaning  

0  0  0  0  0  0  0  Unknown 

0  0  1  0  0  0  1     International  number  in  ISDN  numbering  plan  (Rec.  E.164) 
0  0  1  0  0  1  1     International  number  in  data  numbering  plan  (Rec.  X.121) 

0  1  0  0  0  0  1     National  number  in  ISDN  numbering  plan  (Rec.  E.164) 

1  0  0  0  0  0  1     Local  (directory)  number  in  ISDN  numbering  plan  (Rec.  E.164) 

110  10  0  1     Abbreviated  Number  in  Private  Numbering  plan 

All  other  values  are  reserved 


—  Origin  of  number  and  presentation  status  (octet  3a)  follows: 
Bits 

7  6  5  4  3  2  1  Meaning 

0  0  0  0  0  0  0    Presentation  allowed  of  user-provided  number, 
number  not  screened 

0  0  0  0  0  0  1    Presentation  allowed  of  user-provided  number, 
number  passed  network  screening 

0  0  0  0  0  1  0    Presentation  allowed  of  user-provided  number, 
number  failed  network  screening 

0  0  0  0  0  1  1    Presentation  allowed  of  network-provided  number 

0  1  0  0  0  0  0    Presentation  prohibited  of  user-provided  number, 
number  not  screened 

0  1  0  0  0  0  1    Presentation  prohibited  of  user-provided  number, 
number  passed  network  screening 

0  1  0  0  0  1  0    Presentation  prohibited  of  user-provided  number, 
number  failed  network  screening 

0  1  0  0  0  1  1    Presentation  prohibited  of  network-provided  number 

1  0  0  0  0  1  1    Number  not  available 

All  other  values  are  reserved 


Note  1  —  When  octet  3a  is  omitted,  the  default  value  of  the  Number  Presentation  parameter  for  the  signaled  DN 
value  should  be  used,  if  it  is  available.  If  a  value  for  this  parameter  is  unavailable  (i.e.,  the  signaled  DN  value  either 
fails  screening  or  is  not  screened  by  the  SPCS),  the  presentation  parameter  value  of  the  default  DN  should  be  used. 

Note  2  —  Octet  3a,  bits  7  &  6,  are  for  the  Presentation  indicator;  bits  2  &  1  are  for  the  screening  indicator. 
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—  Digits  (octet  4,  etc.) 


Digits  should  be  represented  by  IA5  characters  whose  encoding  is  shown  below: 

Bits 

7  6  5  4  3  2  1  Meaning 


0 

1 

1 

0  0  0  0 

o 

0 

J 

1 

0  0  0  1 

yj  \j  \j  x 

1 

u 

3 

1 

1 

UU  1  0 

2 

0 

1 

1 

0  0  11 

3 

0 

1 

1 

0  100 

4 

0 

1 

1 

0  10  1 

5 

0 

1 

1 

0  110 

6 

0 

1 

1 

0  111 

7 

0 

1 

1 

1  000 

8 

0 

1 

1 

100  1 

9 

All  other  values  reserved 


Codings  At  Originating  Party  Interface 

The  calling  party  number  information  element  should  only  be  accepted  when  in  the  SETUP  message.  When  the  type 
of  number  and  numbering  plan  indicator  indicates  "local  number  in  the  ISDN  (E.164)  numbering  plan",  the  calling 
party  number  information  element  should  contain  a  7-digit  local  number.  When  the  type  of  number  and  numbering 
plan  indicator  indicates  "national  number  in  the  ISDN  (E.164)  numbering  plan"  the  calling  party  number  information 
element  should  contain  a  10-digit  national  number. 

In  the  network  to  user  direction  (n  ->  u).  the  coding  and  delivery  of  this  IE  depends  on  the  definition  of  the  Calling 
Line  ID  service.  For  private  networks,  this  IE  can  contain  the  following  codepoints:  abbreviated  type  of  number, 
and  private  numbering  plan,  and  extra  digits  such  as  A,  B,  C,  and  D.  (as  per  IE5) 
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Attachment  D 

(of  Appendix  B) 


Network  —  Specific  facilities  Information  Element  Examples 

One  recommended  use  for  the  Network  Specific  Facilities  information  element  is  to  indicate  which  type  of  network 
facilities  are  being  invoked  at  the  specified  network.  In  this  arrangement,  many  different  facility  types  are  allowed 
to  share  a  single  Primary  Rate  Interface.  Examples  of  the  different  DS-1  facility  types  allowed  are: 

Private  Lines 
Inwats  Circuits 
Outwats  Circuits 
Foreign  Exchange  (FX) 
Tie  Trunks 
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Attachment  E 

(of  Appendix  B) 

(editor's  note:  the  sections  contained  in  the  brackets  are  unchanged  from  the  original  Annex  D) 
Annex  D  —  Extensions  for  symmetric  (peer-to-peer)  call  operation 
This  annex  is  part  of  NIU  90-302. 

Symmetric  call  operation,  or  peer-to-peer  call  operation,  shall  be  applied  to  the  switches  within  a  private  network 
where  all  switches,  such  as  PBXs  and  central  office  switches  serving  business  group  users  are  considered  as  peers. 
For  example,  PBX-to-PBX,  PBX-to-Centrex,  Centrex-to-Centrex. 

D.l  Additional  message  handling 

[In  symmetric  applications,  the  SETUP  message  will  contain  a  Channel  Identification  information  element  indicating 
a  particular  B-channel  to  be  used  for  the  call.  A  point-to-point  data  link  shall  be  used  to  carry  the  SETUP  message.] 

The  following  procedures  shall  be  followed  for  symmetrical  operation.  The  call  control  states  followed  should  be 
the  symmetric  states  defined  in  section  D.6. 

D.l.l  Call  Request 

The  initiator  of  the  call  shall  follow  the  network  side  procedures  described  in  section  5.2.1. 
D.l. 2  B-channel  Selection  —  symmetric  interface 

[Only  B-channels  controlled  by  the  same  D-channel  will  be  the  subject  of  the  selection  procedure.  The  selection 
procedure  is  as  follows: 

a)  The  SETUP  message  will  indicate  one  of  the  following: 

1)  channel  is  indicated,  no  acceptable  alternative,  or 

2)  channel  is  indicated,  any  alternative  is  acceptable. 

b)  In  cases  1)  and  2),  if  the  indicated  channel  is  acceptable  and  available,  the  recipient  of  the  SETUP 
message  reserves  it  for  the  call.  In  case  2),  if  the  recipient  of  the  SETUP  message  cannot  grant 
the  indicated  channel,  it  reserves  any  other  available  B-channel  associated  with  the  D-channel.] 

c)  The  recipient  of  the  SETUP  message  indicates  the  selected  B-channel  in  a  CALL  PROCEEDING, 
message  transferred  across  the  interface  and  enters  the  Incoming  Call  Proceeding  state.  If  an 
ALERTING  or  a  CONNECT  message  is  received  in  response  to  a  SETUP  message,  the  call  should 
continue  to  be  processed,  if  the  channel  indicated  is  acceptable  to  the  initiator  of  the  call,  in 
accordance  with  Sections  D.  1 .5. 1  and  D.  1 .8,  respectively.  Although  these  are  acceptable  responses, 
a  CALL  PROCEEDING  message  is  the  recommended  response  to  a  SETUP  message. 

d) 

e)  In  case  1)  if  the  indicated  B-channel  is  not  available,  or  in  case  2)  if  no  B-channel  is  available,  a 
RELEASE  COMPLETE  message  with  a  cause  value  of  No.  44  "requested  circuit/channel  not 
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available"  or  No.  34  "no  circuit/channel  available"  respectively  is  returned  to  the  initiator  of  the 
call.  The  sender  of  this  message  remains  in  the  Null  state. 


f)  If  the  channel  indicated  in  the  CALL  PROCEEDING,  message  is  unacceptable  to  the  initiator  of 
the  call,  it  clears  the  call  in  accordance  with  Section  5.3.  If  an  ALERTING  or  a  CONNECT 
message  is  received  in  response  to  a  SETUP  message  and  the  channel  indicated  is  unacceptable 
to  the  initiator  of  the  call,  it  clears  the  call  in  accordance  with  section  5.3.  Although  these  are 
acceptable  responses,  a  CALL  PROCEEDING  message  is  the  recommended  response  to  a  SETUP 
message. 

D.1.3  Invalid  Call  I/formation 

The  recipient  of  a  SETUP  message  shall  follow  the  network  side  procedures  described  in  section  5.1.4. 
D.1.4  Compatibility  Checking 

The  recipient  of  a  SETUP  message  shall  follow  the  user  side  procedures  described  in  section  5.2.2. 
D.1.5  Call  Confirmation 

Upon  receipt  of  a  SETUP  message,  the  equipment  enters  the  Call  Present  state.  Valid  responses  to  the  SETUP 
message  are  a  CALL  PROCEEDING,  or  a  RELEASE  COMPLETE  message.  If  an  ALERTING  or  a  CONNECT 
message  is  received  in  response  to  a  SETUP  message,  the  call  should  continue  to  be  processed,  if  the  channel 
indicated  is  acceptable  to  the  initiator  of  the  call,  in  accordance  with  Sections  D.1.5. 1.  and  D.1.8,  respectively. 
Although  these  are  acceptable  responses,  a  CALL  PROCEEDING  message  is  the  recommended  response  to  a  SETUP 
message. 

If  the  indicated  channel  is  acceptable  to  the  initiator  of  the  call,  the  initiator  shall  attach  to  the  indicated  B-channel 
according  to  the  procedures  in  Annex  N. 

D. 1.5.1  Receipt  of  CALL  PROCEEDING  and  ALERTING 

The  Initiator  of  a  call  shall  follow  the  network  side  procedures  in  section  5.2.5.2. 

D.1.5. 2  Clearing  during  incoming  call  establishment 

The  initiator  of  a  call  shall  follow  the  network  side  procedures  in  section  5.2.5.3. 
D.1J.3  Call  Failure 

The  initiator  of  a  call  shall  follow  the  network  side  procedures  in  section  5.2.5.4. 
D.1.6  Clearing  by  the  called  user  employing  user-provided  tones/announcements 

When  tones  or  announcements  are  provided  in  conjunction  with  call  clearing,  the  party  providing  the  in -band 
treatment  shall  send  a  PROGRESS  message. 

D.1.7  Call  Accept 

The  recipient  of  the  call  shall  follow  the  user  side  procedures  in  section  5.2.7. 
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D.1.8  Active  indication 

Upon  receipt  of  a  CONNECT  message,  the  initiator  of  the  call  shall  respond  with  a  CONNECT  ACKNOWLEDGE 
message  and  enter  the  Active  State  (see  sec.  5.2.8  network  side  procedures). 

D.1.9  Call  Clearing 

D. 1.9.1  Normal  Call  Clearing 

Then  sender  of  the  DISCONNECT  message  shall  follow  the  user  side  procedures  in  section  5.3.3.  The  recipient  of 
the  DISCONNECT  message  shall  follow  the  network  side  procedures  in  section  5.3.3. 

D.2  Timers  for  call  establishment 

The  timers  described  in  section  9  table  7  shall  be  implemented  along  with  the  corresponding  procedures  for  action's 
taken  upon  expiration  of  these  timers.  The  default  of  T310  should  be  extended  to  20  seconds.  In  addition,  timer 
T309  shall  be  mandatory. 

D.3  Call  collisions 

In  symmetric  arrangements,  call  collisions  can  occur  when  both  sides  simultaneously  transfer  a  SETUP  message 
indicating  the  same  channel.  In  the  absence  of  administrative  procedures  for  assignment  of  channels  to  each  side 
of  the  interface,  the  following  procedure  is  employed. 

First,  one  side  of  the  interface  will  be  designated  the  "controlling  function"  and  the  other  side  of  the  interface  will 
be  designated  the  "responding  function".  This  can  be  accomplished  by  administering  the  Layer  2  Command/ 
Response  bit.  The  controlling  function  is  assigned  "command"  and  has  control  of  all  the  channels  on  the  interface. 
The  responding  function  is  assigned  "response".  Second,  for  the  three  possible  scenarios  where  the  same  channel 
is  indicated  by  combinations  of  preferred  and  exclusive  from  the  responding  function  and  controlling  function,  the 
following  procedure  is  used: 

a)  "controlling  function"  preferred,  "responding  function"  preferred: 

The  "controlling  function"  preferred  channel  is  awarded  and  an  alternate  channel  is  indicated  in 
the  first  response  to  the  "responding  function"  SETUP  message. 

b)  "controlling  function"  exclusive,  "responding  function"  exclusive: 

The  "controlling  function"  exclusive  channel  is  awarded  and  the  "responding  function"  SETUP 
message  is  cleared  with  a  RELEASE  COMPLETE  message  with  cause  No.  34  "no  circuit/channel 
available". 

c)  "controlling  function"  preferred,  "responding  function"  exclusive;  or  "controlling  function" 
exclusive,  "responding  function"  preferred: 

The  side  of  the  interface  with  an  exclusive  indicator  in  a  SETUP  message  is  awarded  the  channel 
and  an  alternate  channel  is  indicated  in  the  first  response  to  the  side  using  a  preferred  indicator  in 
the  SETUP  message. 

Channel  identification  is  allowed  in  both  directions  for  ALERTING  and  CONNECT. 
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DA       Restart  Procedures 
See  section  5.5. 

D.5       Handling  of  Error  Codes 
See  section  5.8. 

D.6       Call  control  states  for  symmetric  call  operation 

The  state  below  are  used  in  association  with  call  references  other  than  the  global  call  reference,  and  apply  to 
symmetric  interfaces.  The  Outgoing  side  is  the  side  of  the  symmetric  interface  that  transmits  the  SETUP  message, 
while  the  incoming  side  is  the  recipient  of  the  SETUP  message. 

D.6.1     Null  State  (SO) 

No  call  exists. 

D.6.2     Call  Initiated  (SI) 

This  state  exists  for  an  outgoing  call  when  the  Outgoing  Side  has  sent  a  request  for  call  establishment  to  the 
Incoming  Side  but  has  not  yet  received  a  response. 

D.6.3     Outgoing  Call  Proceeding  (S3) 

This  state  exists  for  an  outgoing  call  when  the  Outgoing  Side  has  received  acknowledgement  that  the  Incoming  Side 
has  received  all  call  information  necessary  to  effect  call  establishment. 

D.6.4     Call  Delivered  (S4) 

This  state  exists  for  an  outgoing  call  when  the  Outgoing  Side  has  received  from  the  Incoming  Side  an  indication  that 
the  called  user  is  being  alerted. 

D.6.5     Call  Present  (S6) 

This  state  exists  for  an  incoming  call  when  the  Incoming  Side  has  not  yet  responded  to  the  request  from  the 
Outgoing  Side  for  call  establishment. 

D.6.6     Call  Received  (S7) 

This  state  exists  for  an  incoming  call  when  the  Incoming  Side  has  indicated  to  the  Outgoing  Side  that  the  called  user 
is  being  alerted. 

D.6. 7     Connect  Request  (S8) 

This  state  exists  for  an  incoming  call  when  the  Incoming  Side  has  indicated  to  the  Outgoing  Side  that  the  called  user 
has  answered  the  call. 

D.6. 8    Incoming  Call  Proceeding  (S9) 
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This  state  exists  for  an  incoming  call  when  the  Incoming  Site  has  sent  to  the  Outgoing  Side  acknowledgement  thai 
it  has  received  all  call  information  necessary  to  effect  call  establishment. 

D.6.9    Active  (S10) 

This  state  exists  for  an  incoming  call  when  the  Incoming  Side  has  received  from  the  Outgoing  Side  an 
acknowledgement  of  the  indication  that  the  called  user  has  answered  the  call.  This  state  exists  for  an  outgoing  call 
when  the  Outgoing  Side  has  received  from  the  Incoming  Side  an  indication  that  the  called  user  has  answered  the 
call. 

D.6.10  Disconnect  Request  (Sll) 

This  state  exists  when  a  Side  has  sent  to  the  other  Side  a  request  to  disconnect  the  user  information  connection  and 
is  waiting  for  a  response. 

D.6.11  Disconnect  Indication  (S12) 

This  state  exists  when  a  Side  has  received  from  the  other  Side  a  request  to  disconnect  the  user  information 
connection  and  has  not  yet  responded. 

D.6.12  Release  Request  (S19) 

This  state  exists  when  a  Side  has  sent  to  the  other  Side  a  request  to  release  the  call  and  has  not  yet  received  a 
response. 
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Attachment  F 

(of  Appendix  B) 

Annex  N  —  Procedures  for  Establishment  of  Bearer  Connection  Prior  to  Call  Acceptance 
This  annex  is  part  of  NIU  90-302. 
N.l  General 

For  some  applications,  it  is  desirable  to  allow  the  completion  of  the  transmission  path  associated  with  a  bearer  service 
prior  to  receiving  call  acceptance.  In  particular,  the  completion  of  the  backward  direction  for  non-peer 
communication  or  both  directions  for  peer-to-peer  communication  (see  Annex  D  for  peer-to-peer  call  operation)  of 
the  transmission  path  prior  to  receipt  of  a  CONNECT  message  from  the  called  user  may  be  desirable  to: 

1)  allow  the  called  user  to  provide  internally-generated  tones  and  announcements  that  are  sent  in-band 
to  the  calling  user  prior  to  answer  by  the  called  user;  or, 

2)  avoid  speech  clipping  on  connections  involving  an  NT2  where  delays  may  occur  in  relaying  the 
answer  indication  within  the  called  user  equipment. 

The  procedures  described  in  this  annex  are  applicable  to  the  speech  and  3.1  kHz  audio  bearer  services,  for  non-peer 
communication  of  both  directions  for  peer-to-peer  communication  (see  Annex  D  for  peer-to-peer  call  operation). 

N.2  Procedures 

Completion  of  the  transmission  path  prior  to  receipt  of  a  call  acceptance  indication  shall  be  provided  in  three  ways: 

1 )  For  peer-to-peer  communications  on  receipt  of  a  CALL  PROCEEDING  message  or  an  ALERTING 
message  indicating  completion  of  successful  channel  negotiation. 

2)  For  non-peer  communication  on  receipt  of  an  ALERTING  message;  and 

3)  For  non-peer  communications  on  receipt  of  a  PROGRESS  message. 

When  criteria  (1)  is  used  to  determine  that  a  transmission  path  should  be  established,  the  sender  of  the  SETUP 
message  shall  connect,  both  directions  of  the  transmission  path  upon  receipt  of  either  a  CALL  PROCEEDING 
message  or  an  ALERTING  message  containing  an  acceptable  B -channel  indication. 

When  criteria  (2)  is  used  to  establish  the  transmission  path,  the  network  shall  connect,  the  backward  direction  of  the 
transmission  path  upon  receipt  of  an  ALERTING  message  assuming  channel  negotiation  procedures  have  been 
successful. 

When  criteria  (3)  is  used  to  establish  the  transmission  path,  the  network  shall  connect,  the  backward  direction  of  the 
transmission  path  upon  receipt  of  a  PROGRESS  message  containing  progress  indicator  1  "call  is  not  end-to-end 
ISDN;  further  call  progress  information  may  be  available  in-band,"  assuming  that  the  user  has  already  returned  a 
CALL  PROCEEDING  message  and  channel  negotiation  procedures  have  been  successful. 

If  an  ALERTING  message  follows  a  PROGRESS  message  containing  progress  indicator  1,  it  should  be  treated  as 
an  unexpected  message. 
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The  network  may  choose  to  further  restrict  when  message(s)  will  result  in  establishment  of  the  transmission  path. 
These  restrictions  may  be  imposed  on  a  per  interface  basis  to  provide  an  administrative  means  for  limiting  potential 
misuse  of  the  early  connection  capabilities. 
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Voluntary  Product  Standards  — Developed  under  procedures  published  by  the  Department  of 
Commerce  in  Part  10,  Title  15,  of  the  Code  of  Federal  Regulations.  The  standards  establish 
nationally  recognized  requirements  for  products,  and  provide  all  concerned  interests  with  a  basis 
for  common  understanding  of  the  characteristics  of  the  products.  NIST  administers  this  program 
as  a  supplement  to  the  activities  of  the  private  sector  standardizing  organizations. 
Consumer  Information  Series  — Practical  information,  based  on  NIST  research  and  experience, 
covering  areas  of  interest  to  the  consumer.  Easily  understandable  language  and  illustrations 
provide  useful  background  knowledge  for  shopping  in  today's  technological  marketplace. 
Order  the  above  NIST  publications  from:  Superintendent  of  Documents,  Government  Printing  Office, 
Washington,  DC  20402. 

Order  the  following  NIST  publications— FIPS  and  NISTIRs—from  the  National  Technical  Information 
Service,  Springfield,  VA  22161. 

Federal  Information  Processing  Standards  Publications  (FIPS  PUB)  — Publications  in  this  series 
collectively  constitute  the  Federal  Information  Processing  Standards  Register.  The  Register  serves 
as  the  official  source  of  information  in  the  Federal  Government  regarding  standards  issued  by 
NIST  pursuant  to  the  Federal  Property  and  Administrative  Services  Act  of  1949  as  amended, 
Public  Law  89-306  (79  Stat.  1127),  and  as  implemented  by  Executive  Order  11717  (38  FR  12315, 
dated  May  11,  1973)  and  Part  6  of  Title  15  CFR  (Code  of  Federal  Regulations). 
NIST  Interagency  Reports  (NISTIR)-A  special  series  of  interim  or  final  reports  on  work 
performed  by  NIST  for  outside  sponsors  (both  government  and  non-government).  In  general, 
initial  distribution  is  handled  by  the  sponsor;  public  distribution  is  by  the  National  Technical 
Information  Service,  Springfield,  VA  22161,  in  paper  copy  or  microfiche  form. 
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